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Abstract 


This  paper  is  concerned  with  both  dialogue  and  process  management 
for  interactive  information  systems  (abbrev.  IISs) •  In  particular, 
the  paper  describes  an  extension  to  TAXIS  [Hylopoulos  et  al  80],  a 
language  for  IIS  design,  to  provide  this  type  of  management. 
Dialogues  between  a  user  and  the  system  are  described  through  a  small 
set  of  primitives  incorporated  into  TAXIS  while  process  control  is 
accomplished  by  incorporating  Hoare*s  I/O  commands  for  communicating 
sequential  processes  [ Hoare  78].  The  overall  organization  and 
structure  of  dialogue  and  process  control  for  a  particular  IIS  is 
achieved  using  scripts,  a  modified  version  of  augmented  Petri  nets 
[Zisman  77],  and  the  TAXIS  conceptual  framework  of  properties, 
classes,  and  the  TS-A  relationship.  A  journal  editing  procedure  is 
used  to  illustrate  the  proposed  extension. 
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1  Introduction 


1.  1  Motivation 

We  are  concerned  with  the  design  of  TAXIS,  a  programming  language 
for  interactive  information  systems  (abbrev.  IISs)  .  IISs  are 
characterized  by  a  large  volume  of  short,  interactive,  and  highly 
predictable  operations  on  a  database.  Each  of  these  operations  can  be 
viewed  as  an  independent  process.  An  IIS  can  be  thought  of  as  a 
collection  of  concurrently  running  processes  that  make  substantial  use 
of  a  database.  Examples  of  such  applications  include  systems  for 
airline  and  hotel  reservations,  inventory  control,  and  credit  card 
verification . 

One  may  ask;  ’’Why  design  yet  another  programming  language?". 
Our  response  is  that  the  high  cost  of  software  development  for  IIS 
applications,  which  are  distinguished  from  other  applications  by  large 
amounts  of  conceptually  simple  detail,  is  partly  due  to  the  inadequate 
programming  facilities  offered  in  such  conventional  languages  as 
COBOL,  PL/1,  and  FORTRAN.  TAXIS  provides  extra  mechanisms,  not  found 
in  these  conventional  languages,  for  the  organization  of  this  detail 
in  an  intellectually  more  manageable  way. 

A  partial  answer  to  the  above  problem  lies  in  the  intergration  of 
database  facilities  with  existing  procedural  languages,  as  exemplified 
by  [Date  75],  [Schmidt  77],  and  [  Wasserman  ^  al  78].  TAXIS  takes  a 
step  along  this  direction  by  integrating  data  with  the  procedures  that 
use  it  (in  the  style  of,  say,  SIMOLA  [Dahl  and  Hoare  72]).  In 
particular,  TAXIS  integrates  relational  database  management 
facilities,  a  means  of  specifying  semantic  integrity  constraints,  and 
an  exception  handling  mechanism  into  a  simple  language  through  the 
concepts  of  class,  property,  and  the  IS-A  relationship.  However 
TAXIS,  as  well  as  other  related  languages,  provide  very  limited 
facilities  for  the  description  of  user  interfaces,  even  though  as 
pointed  out  in  [Carlson  and  Metz  79],  user  interfaces  present  some  of 
the  thorniest  problems  in  IIS  design  and  are  responsible  for  a  major 
part  of  the  high  design  and  implementation  costs.  Moreover,  most 
programming  languages  do  not  address  the  issue  of  coordination  and 
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data  transfer  between  concurrently  running  processes,  although 
languages  such  as  CONCUEEENT  PASCAL  (see  [Brinch  Hansen  75])  and 
CONCUEBENT  SP/K  (see  [Holt  et  al  78])  do  allow  processes  to  share  data 
by  the  use  of  monitors.  This  paper  presents  an  extension  to  TAXIS  to 
include  such  dialogue  and  process  control  facilities.  The  new 
facilities  fit  into  the  TAXIS  conceptual  framework  of  properties, 
classes,  and  the  IS-A  relationship. 

1 . 2  Overview 

Previous  work  by  [  Plylopoulos  ^  a  1  80  j  and  [Wong  81]  has  resulted 
in  the  design  of  that  part  of  TAXIS  that  offers  tools  for  the 
specification  of  the  semantic  component  of  an  IIS,  i.e.  the 
description  of  the  data  structures  and  transactions  constituting  the 
heart  of  an  IIS.  This  paper  is  primarily  concerned  with  the  design  of 
a  second  part  of  TAXIS  which  allows  the  specification  of  the  pragmatic 
component  of  an  IIS,  i.e.  the  description  of  the  processes  that 
conduct  dialogues  with  the  users  and  interact  with  the  database  as  a 
result  of  that  dialogue.  The  parts  of  a  TAXIS  program  that  are  used 
to  represent  these  processes  are  called  scripts.  Another  extension  of 
TAXIS  is  currently  being  investigated  which  will  allow  the 
specification  of  a  syntactic  component  of  an  IIS,  i.e.  the 
specification  of  the  allowable  syntactic  forms  for  messages  exchanged 
between  an  IIS  and  its  users  [Pilote  81]. 

The  pragmatic  component  of  TAXIS  serves  as  the  control  mechanism 
for  initiating,  conducting,  and  terminating  dialogues  between  an  IIS 
and  its  users.  That  is,  it  restricts  the  possible  long  term  sequences 
of  actions  the  system  can  perform.  Which  particular  actions  are 
actually  performed  depends  on  the  user's  input  and  the  current  state 
of  the  system.  The  pragmatic  component  also  provides  the  context 
under  which  dialogues  take  place.  This  means  that  a  dialogue  between 
a  user  and  an  IIS  can  only  proceed  in  expected  ways.  For  example,  the 
editor  of  a  journal  cannot  accept  a  paper  for  publication  before  that 
paper  has  been  refereed.  Thus  the  pragmatic  component  of  TAXIS 
provides  the  organization  and  structure  for  user/IIS  dialogues  and 
serves  as  the  interface  between  the  syntactic  and  semantic  components 
of  TAXIS. 
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2  Designing  the  Semantic  Component  of  an  IIS 

2. 1  TAXIS  Concepts 

It  is  not  the  purpose  of  this  paper  to  describe  the  tools  offered 
by  TAXIS  for  the  design  of  the  semantic  component  of  an  IIS  (see 
[Mylopoulos  et  al  80]  for  this).  However  this  section  presents  some 
of  the  basic  concepts  of  the  language,  necessary  for  the  understanding 
of  the  remainder  of  the  paper. 

The  basic  types  of  objects  in  TAXIS  are  tokens,  classes.  and 

metaclasses.  Tokens  are  the  constants  of  a  TAXIS  program.  For 

example,  joe-editor,  representing  a  particular  editor,  is  a  token.  A 
class,  EDITOR,  represents  the  concept  of  an  editor  and  can  have  as 
instances  tokens,  representing  particular  editors  such  as  joe-editor. 
The  extension  of  a  class  is  the  set  of  its  instance  tokens.  Classes 
and  tokens  have  properties  through  which  they  can  be  related  to  other 
classes  and  tokens.  For  example,  some  of  the  properties  that  can  be 
associated  with  the  class  EDITOR  represent  the  information  that 
editors  in  general  can  have  a  name  and  an  address  and  can  edit  one  or 
more  journals.  These  are  called  definitional  properties  of  the  class 
EDITOR.  For  tokens,  properties  represent  specific  facts  rather  than 

abstract  rules  such  as  those  just  presented  for  EDITOR.  For  example, 

the  token  joe-editor  can  have  properties  representing  facts  such  as 
joe-editor’s  name  is  ’EDITOR, JOE, E. * ,  his  address  is 

*38  EDITORS  LANE',  and  one  of  the  journals  he  is  editing  is 
journal- 107.  These  are  called  factual  properties  of  the  token 
joe-editor. 

More  formally,  TAXIS  properties  can  be  represented  as  triples 
consisting  of  one  or  more  subjects .  an  attribute  or  property  name,  and 
^  (abbrev.  p-value)  .  Some  of  the  definitional 

properties  of  the  class  EDITOR  are: 

<EDITOR,name,NAME> 

<EDIT0R, address, ADDRESS> 

<EDIT0E, journal, setiof  JOURNAL> 

while  some  of  the  factual  properties  of  the  token  joe-editor  are: 


(joe -edit or , na  me, *  EDI TOE , JOE, B. * ) 

(joe-editor, address, *38  EDITORS  LANE*) 

(joe- editor, journal, {journal- 107, journal- 3 16, journal- 4 2 9) ) 
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If  a  property  has  only  one  subject  then  it  is  called  a  simple 
property;  otherwise  it  is  called  a  complex  property.  For  example: 

<  (AUTHOR, TITLE)  ,paper , PAPER> 

defines  a  complex  property  whose  subjects  are  the  classes  AUTHOR  and 
TITLE,  whose  attribute  is  paper,  and  whose  p-value  is  the  class  PAPER. 
This  property  represents  the  fact  that  each  combination  of  an  author 
and  a  title  can  have  a  particular  paper  associated  with  it. 

If  joe-editor  is  an  instance  of  EDITOR  and  <EDITOR, name , NAM E>  is 
a  definitional  property  of  EDITOR,  joe-editor  must  have  a 

corresponding  factual  property  (joe-editor, name, x) ,  where  x  is  an 
instance  of  NAME.  This  close  relationship  between  a  definitional 
property  and  its  corresponding  factual  properties  is  known  as  the 
iS.4ii2i.ioil  principle.  We  say  that  the  definitional  properties 
of  a  class  induce  factual  properties  for  their  instances.  To  traverse 
the  schema  defined  within  a  TAXIS  program  by  its  classes  and  their 
definitional  properties  we  use  the  definitional  propert y  selector. 
For  the  property  (EDITOR, name,  NAME)  the  expression  ''EDITOR ..  name" 
returns  as  its  value  NAME.  Similarly,  to  obtain  p-values  of  factual 
properties  we  use  the  factual  property  selector.  For  the  property 
I  joe-editor , name ,* EDITOR, JOE, B. * )  the  expression  " joe-editor. name" 
returns  the  value  *  EDITOR, JOE, B. * . 

Metaclasses  are  similar  to  classes  in  every  respect,  except  that 
their  instances  are  classes  rather  than  tokens.  TAXIS  allows  an  IIS 
designer  to  specify  his  own  metaclasses  as  well  as  providing  him  with 
some  predefined  metaclasses  such  as  VARIABLE-CLASS  and 
TRANSACTION-CLASS. 

2«.2  Examples 

A  variable  class  behaves  like  a  database  relation  in  that  its 
collection  of  instances  can  be  changed  by  insertions  and  deletions. 
EDITOR  can  be  defined  as  the  variable  class: 

VARIABLE-CLASS  EDITOR  with 
keys 
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editor:  (name, address) 
characte r i sties 

name:  TUfFIE 
address: ADDRESS 
phone: PHONE 

journal : set-of  JOURNAL 
area: set^of ~^RE A 
attributes 

profession: PROFESSION 

num-papers-editinq: NON-NEGATI VE-INTEGER  default  0 
code:EDITOR-CODE 
end ; 


Property  categories  are  used  to  express  what  aspects  of  the  structure 
and  behavior  of  a  metaclass  each  of  its  properties  convey.  A  variable 
class  has  three  property  categories:  keys .  characteristics,  and 
attributes.  The  key  property  of  this  class  defines  a  complex 
definitional  property  representing  the  fact  that  each  editor  is 
uniquely  identified  by  a  name/address  pair.  Characteristic  properties 
are  time  invariant  in  that  their  p-values  cannot  be  changed. 
Attribute  properties  are  time  varying  in  that  they  can  have  their 
p-*values  changed. 


The  ’'journal”  and  "area”  properties  can  have  one  or  more  p-values 
simultaneously,  i. e.  an  editor  can  be  responsible  for  one  or  more 
journals  at  a  time  and  can  have  expertise  in  one  or  more  areas.  The 
"num-papers-editing”  property  has  a  default  value  of  0  and  can  have  as 
its  p“Value  any  integer  greater  than  or  equal  to  0.  It  should  perhaps 
be  emphasized  here  that  tokens  (surrogates  in  [Codd  80])  rather  than 
actual  values  are  maintained  in  a  class’s  extension. 


The  REFEREE  and  AUTHOR  classes  can  be  defined  in  much  the  same 
way  as  EDITOR.  For  example,  the  REFEREE  class  can  be  specified  as: 


VARIABLE-CLASS  REFEREE  with 
ke^s 

referee:  (name, address) 
characteristics 

name: 

address : ADDRESS 
phone: PHONE 
area:set-of  AREA 
attributes  "" 

"’profession:  PROFESSION 

num-papers-refereeing: NON-NEGATIVE-INTEGEE  default  0 
code : Re FERE E-CO  DE 
end 


An  aggregate  class  is  comparable  to  the  PASCAL  record  type, 
example,  the  address  attribute  of  EDITOR  might  be  defined  as: 


For 
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AGGREGATE-CLASS  ADDRESS  with 
characteristics 
street:  ST!^EET 
city:  CITY 
country:  COUNTRY 
end ; 


The  extension  of  this  class  is  determined  by  the  cross  product  of  the 
extensions  of  its  p-values,  i.e.  STREET,  CITY,  and  COUNTRY.  That  is, 
instances  of  this  class  are  all  tuples  with  first  component  an 
instance  of  STREET,  second  component  of  CITY,  and  third  component  of 
COUNTRY. 


Finitely-defined  classes  are  similar  to  PASCAL  scalar  types.  For 
example,  the  PROFESSION  class,  enumerating  all  allowable  professions, 
would  be  specified  as: 


PROFESSION : =  {I ' computer- scientist ' , *  physicist  * , *  historian  * , . . .  | } 


A  particular  instance  of  EDITOR,  REFEREE,  or  AUTHOR  will  have  an 
instance  of  PROFESSION  associated  with  it  through  its  "profession" 
attribute. 


Finally,  a  phone  number  can  be  an  instance  of  a  formatted  class. 


FORMATTED-CLASS  PHONE  with 

{1  '  I*  1}  a)REPEAT  JDIGITTEf  aJ  {  |  ')  *  1}  ^REPEAT  (DIGIT,?) 
end ; 


Now  all  instances  of  PHONE  would  have  the  format  (ddd) ddddddd  where  d 
is  a  digit. 


Transaction  classes  behave  like  procedures.  For  example,  if  some 
author  submits  a  paper  for  publication,  referees  must  review  that 
paper.  We  define  a  transaction  ADD-REFEREE  which  inserts  a  referee 
token  into  a  list  REFLIST  if  that  token  is  not  currently  in  REFLISI's 
extension.  The  transaction  returns  a  value  of  'yes*  or  'no'  to 
indicate  whether  the  insertion  takes  place  or  not. 


TRANSACTION  ADD-REFEREE  with 
parameters 

'adj- referee:  (referee ,  author ,  editor,  paper) 
locals 

referee: REFEREE 
author: AUTHOR 
editor: EDITOR 
paper : PAPER 
rf lt:REFLIST 

insert-status: YES-OR-NO  default  'yes' 
preregs 

Fef-not-auth?: not  (referee  =  author) 

.  ILIRIIJAL-REFEREE  (r :  ref  eree,  a:author- e  :editor  ,p:  paper) 
paper-limrE? : referee. num-papers-refereeing  <  10 
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exc  ILLEGAL-REFEREE  (r ; referee, a: author , e: editor , p: paper) 

actions 

insert:  (begin 

aTTger-obiect  rflt  from  REF LI ST 
where T  (i:rrt.  ref  eree=referee) 

~anh  |rflt.author=author) 
an3  (rflt. paper  =  paper)) 
a2:  ifTnot  (r  f  lt=nothin£j  ) 

“then  inserh-s€a€us< — *no* 
else  begin 

a2l : insert-ob iect  rflt  in  EEFLIST 
^  wihE (f f lt7ref eree?^-ref eree , 
r f It. author< — author , 
rflt. paper< — paper) 
a22:referee. num- papers- ref ereeing  < — 
referee. num-papers-refereeing  +  1 

end 

end) 

returns 

rtn:  insert-status 
end ; 


The  parameter  list  property  of  the  above  transaction  defines  the 
complex  definitional  property: 

< (REFEREE, AUTHOR, EDITOR, PAPER) , add-referee , ADD-EEFEREE> 


Actual  parameter  values  of  ADD-REFEREE  define  a  complex  factual 
property  whose  p-value  is  the  value  returned  by  executing  the 
transaction  called  with  those  parameters.  For  example: 

{ (joe- referee, joe-author, joe -edit or , paper  1)  , add-referee , 'yes' ) 

is  a  possible  factual  property  of  the  transaction  (provided  a 
successful  insertion  has  been  done) . 

A  transaction  class  is  similar  to  a  variable  class  in  that  it  has 
a  time-varying  extension.  When  a  call  to  ADD-REFEREE  is  made,  a  new 
token  representing  an  execution  instance  of  that  transaction  is  first 
created  and  added  to  ADD-REFEREE' s  extension.  While  that  token  is  in 
ADD-REFEREE ' s  extension,  it  is  possible  to  examine  the  factual 
p-values  of  its  properties.  The  factual  p-value  of  a  local  property 
is  the  value  it  currently  has  (which  is  value  unknown  if  the  property 
is  currently  undefined).  Prerequisite,  action,  and  return  properties 
do  not  have  factual  p-values;  attempts  to  access  their  factual 
p-values  will  always  result  in  value  nothing  being  returned.  As  for 
all  other  TAXIS  classes,  the  definitional  p-values  of  a  transaction 
are  simply  the  definitions  of  those  classes  that  each  of  its 
individual  properties  are  instances  of. 
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Local  properties  define  the  local  variables  of  the  transaction, 
with  all  parameters  being  declared  as  locals.  The  above  transaction 
has  four  parameters  "referee",  "author",  "editor",  and  "paper"  and  two 
local  variables  "rflt"  and  "insert-status"  declared  in  its  local 
category.  The  "insert-status"  property  is  initially  assigned  a  value 
of  'yes*  using  a  default  clause. 

The  prerequisite,  action,  and  return  properties  of  a  transaction 
class  must  have  instances  of  the  metaclass  expression  class  as  their 
definitional  p-values.  Prerequisite  properties  are  TAXIS  boolean 
expressions  without  side  effects  while  action  and  return  properties 
are  TAXIS  non-boolean  expressions  with  side  effects.  The  body  of  a 
transaction  is  executed  by  first  evaluating  all  prerequisite 
conditions.  If  all  of  them  evaluate  to  true  then  the  action 
properties  are  executed  in  sequential  order  followed,  lastly,  by  the 
execution  of  the  return  property. 

The  body  of  the  ADD-EEFEEEE  transaction  is  executed  by  first 
evaluating  the  two  prerequisite  properties  "ref-not-auth ?"  and 
"paper-limit?".  If,  indeed,  the  referee  and  the  author  are  not  the 
same  person  and  the  referee's  workload  is  fewer  than  10  papers,  then 
the  "insert"  action  property  is  executed.  This  property  is  a  compound 
property  consisting  of  two  properties  "insert.. a1"  and  "insert. .a2". 
The  "insert.. a1"  property  assigns  a  token  to  local  variable  "rflt"  if 
it  can,  Ilf  not,  the  special  TAXIS  token  nothing  is  assigned  by 
default.)  The  "insert. .a2"  property  checks  "rflt"*s  value;  if  it  is 
nothing  (indicating  the  referee  is  not  currently  in  EEFLIST)  then  the 
compound  property  consisting  of  two  properties  "insert .. a2. . a2 1 "  and 
"insert. . a2. . a22"  is  executed.  The  first  of  these  inserts  a  token 
into  EEFLIST  for  the  referee  (with  "insert-status"  keeping  the 
defaulted  value  'yes').  The  second  increments  the  number  of  papers 
for  that  referee  by  one.  If,  on  the  other  hand,  "rflt"'s  value  is  not 
equal  to  nothinq  (indicating  the  referee  already  is  refereeing  the 
author's  paper),  then  "insert-status"  is  simply  assigned  value  'no* 
and  no  insertion  is  done.  Finally,  the  return  property  returns 
"insert-status" * s  value  as  the  transaction *s  factual  p-value. 

If  any  of  the  prerequisite  properties  of  a  transaction  evaluate 
to  false,  an  instance  of  the  metaclass  EXCEPTION-CLASS  must  be  raised, 
i. e.  created.  Thus,  if  either  the  "ref-not-auth?"  or  "paper-limit?" 
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prerequisite  properties  fail,  an  instance  of  ILLEGAL-EEFEREE  is 
raised.  This  class  can  be  defined  as: 

EXCEPTION-CLASS  ILL EGAL- REFEREE  with 
attributes  ^ 

r :  IREFEREE 
a: AUTHOR 
e : EDITOR 
p: PAPER 
eng; 

If  an  instance  of  this  class  is  created,  its  factual  properties  are 
assigned  p-values  through  the  associations  "r : ref eree" ,  "aiauthor”, 
”e:editor",  and  ”p:paper''  present  in  the  “ref-not-auth?  •'  and 
"paper-limit?"  exception  properties. 

When  an  exception  is  raised  within  a  transaction,  the  caller  of 
the  transaction  indicates  what  should  be  done  to  handle  it  by 
specifying  in  its  calling  expression  a  complex  property  of  the  form: 

<  (S  1,S2)  ,eh1,V> 

where  subjects  SI  and  S2  always  specify  an  expression  class  and  an 
exception  class  respectively  and  V  is  the  exception  handler,  which  may 
be  either  a  transaction  or  a  script  that  takes  as  its  only  parameter 
S2.  For  example,  to  indicate  that  the  exception  handler  FIND-NEW-EEF 
should  be  called  if  an  instance  of  ILLEGAL-REFEREE  is  raised,  we  might 
write  in  the  calling  expression  of  the  CALLER  transaction  or  script: 

add:  add- referee  (ref ,auth,ed, paper) 

exc-handler  eh1  for  ILLEGAL-REFEREE 
rs”TOTIFTTET7-REF 

This  defines  the  complex  property 

< (add- referee (ref , auth , ed , paper) , ILLEGAL- REFER EE) ,eh1 , FIND-NEW -REF> 

where  add-referee (ref , auth, ed , paper)  is  the  definitional  p-value  of 
CALLER., add.  Now,  when  an  instance  of  ILLEGAL-REFEREE  is  raised 
during  the  evaluation  of  the  "add-referee (ref , auth, ed, paper)  " 
expression  in  CALLER,  the  called  transaction  ADD-REFEREE  is  terminated 
and  FIND-NEW-REF  is  called  with  the  newly  created  exception  instance 
of  ILLEGAL-REFEREE  as  its  only  argument.  From  the  factual  properties 
of  this  instance,  FIND-NEW-REF  should  determine  the  circumstances  of 
the  exception  and  hopefully  resolve  the  situation.  After  the 
successful  execution  of  FIND-NEW-REF,  control  returns  to  the  next 
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executable  statement  in  CALLER.  Since  FIND-NEW-EEF  will  need  to 
conduct  a  dialogue  with  the  editor  in  order  to  obtain  a  suitable  new 
referee,  it  will  be  specified  as  a  script  (see  the  next  section  for 
the  details) . 

The  exception  handler  is  specified  by  the  calling  transaction  or 
script  (rather  than  in  the  called  transaction)  so  that  different 
transactions  or  scripts  can  specify  different  exception  handlers  as 
the  situation  warrants.  The  exception  handling  mechanism  outlined 
above  is  an  adaption  of  Wasserman’s  procedure-oriented  exception 
handling  [ Wasserman  77]  with  modifications  so  that  it  can  be  treated 
within  the  TAXIS  framework  of  classes,  properties,  and  the  IS-A 
relationship. 

2^.3  The  IS-A  Relationship 

The  type  of  abstraction  emphasized  in  TAXIS  is  based  on  the  IS-A 
relationship  [Quillian  68]  and  facilitates  a  new  design  methodology 
for  IISs  which  we  call  stepwise  refinement  through  specialization 
[Wong  81].  We  see  this  as  being  used  in  conjunction  with  stepwise 
refinement  through  decomposition  [ Wirth  71],  which  is  the  dominant 
program  design  methodology  now  in  use.  A  TAXIS  program  is  viewed  as  a 
collection  of  classes  organized  into  a  specialization  hierarchy.  Not 
only  are  data  classes  organized  in  the  IS-A  hierarchy  (in  the  manner 
similar  to  that  of  [Smith  and  Smith  77])  but  so  are  all  procedural 
(i.e.  transaction  and  script)  classes. 

We  say  SCIENCE-EDITOR  IS-A  (i.e.  is  a  specialization  of)  EDITOR 
if  every  instance  of  SCIENCE-EDITOR  is  also  an  instance  of  EDITOR. 
SCIENCE-EDITOR  has  all  the  properties  of  EDITOR  in  addition  to  new 
properties  defined  in  SCIENCE- EDITOR.  SCIENCE-EDITOR  can  also 
specialize  any  of  the  properties  it  inherits  from  EDITOR.  For 
example : 

VARIABLE-CLASS  SCIENCE-EDITOR  isa  EDITOR  with 
attributes  ~ 

profession:  SCIENTIST 
status: STATUS 
end ; 

The  SCIENCE-EDITOR  class  inherits  the  "name”,  "address",  "phone", 
"journal",  "area",  "num-papers-editing" ,  and  "code"  properties  of 
EDITOR  but  specializes  the  "profession"  property  to  have  values  of 
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class  SCIENTIST.  This  makes  sense  only  if  SCIENTIST  is  a 
specialization  of  PROFESSION.  That  is; 

SCIENTIST:^ {1 ’computer-scientist* , ’physicist* , . . . 1 }  isa  PROFESSION 

SCIENTIST  has  as  instances  only  scientific  professions,  which 
constitute  a  subset  of  all  possible  professions  enumerated  by 
PROFESSION.  In  addition,  SCIENCE-EDITOR  has  a  new  "status"  property 
that  EDITOR  does  not  have.  The  SCIENCE-EDITOR  class  can  be  further 
specialized  to  classes  such  as  COMP-SCI-EDITOR,  PHYSICS-EDITOR,  etc. 
by  adding  or  specializing  properties  relevant  to  those  specific 
classes.  For  example,  COMP-SCI-EDITOR  can  be  defined  as  the  class; 

VARIAB;.E-CLASS  COMP-SCI-EDITOR  i^  SCIENCE-EDITOR  with 
attributes 

profession: COMPUTER-SCIENTIST 
member-acm lYES-OR-NO 
member-ieee; YES-OR-NO 
end 

For  COMP-SCI-EDITOR  to  be  a  valid  specialization  of  SCIENCE- EDITOR , 
COMPUTER-SCIENTIST  would  have  to  be  a  specialization  of  SCIENTIST. 
That  is; 

COMPUTER-SCIENTIST;={J ’computer-scientist* 1}  isa  SCIENTIST 

The  "member-acm"  and  "member-ieee"  properties  are  new  properties  not 
inherited  from  SCIENCE-EDITOR.  Their  p-values  indicate  whether 
particular  editors  are  members  of  the  respective  societies. 
Similarly,  the  REFEREE  and  AUTHOR  classes  can  be  specialized  along  the 
same  lines  as  EDITOR,  i.e.  to  SCIENCE-REFEREE,  SCIENCE- AUTHOR, 
COMP-SCI-REFEREE,  COMP-SCI-AUTHOR,  PHYSICS-REFEREE,  PHYSICS- AUTHOR , 
etc.  Diagram  1  shows  some  of  the  specializations  possible  for  EDITOR 
and  REFEREE  (*)  . 

The  IS- A  hierarchy  need  not  form  a  tree;  it  is  possible  for  a 
class  to  have  two  or  more  parent  classes,  i.e.  a  class  can  be  a 
specialization  of  two  or  more  classes.  For  example,  a  class 


I*)  Instead  of  defining  the  EDITOR  and  REFEREE  classes  separately  as 
in  section  2.2  we  could  first  have  defined  a  class  PERSON  containing 
information  about  people  in  general  and  then  specified  EDITOR  and 
REFEREE  as  specializations  of  PERSON  (by  adding  or  specializing 
properties  relevant  to  editors  and  referees) ,  Although  the  net  effect 
of  specifying  EDITOR  and  REFEREE  in  this  manner  is  the  same  as 
specifying  them  separately  as  above,  this  specification  of  the  two 
classes  is  more  in  the  TAXIS  spirit  of  stepwise  refinement  through 
specialization. 
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EDITOR-EEFEREE  representing  all  persons  who  are  both  editors  and 
referees,  can  be  a  specialization  of  both  EDITOR  and  REFEREE. 

VARIABLE-CLASS  EDITOR-REFEREE  isa  EDITOR , REFER  EE  with 
attributes 

codeTEDIT OR -REFER EE -CODE 
end 

In  this  case,  EDITOR-REFEREE  inherits  the  union  of  all  p-values  of 
both  classes.  Instances  of  EDITOR-EEFEREE  have  "name",  "address", 
"phone",  "journal",  "area",  "profession",  "num-papers-editing" , 
"num-papers-ref ereeing" ,  and  "code"  p-values.  It  should  be  noted  that 
"code"  is  an  instance  of  both  EDITOR-CODE  and  REFEREE-CODE,  i.e. 
EDITOR-R EFEEEE-CODE  must  be  a  specialization  of  both  EDITOR-CODE  and 
REFEREE-CODE.  Of  course,  EDITOR-REFEREE  can  now  be  further 
specialized  in  the  same  manner  as  for  other  variable  classes.  Diagram 
1  indicates  two  possible  specializations,  SCI-ED-REF  and  ARTS-ED-REF. 

As  mentioned  earlier,  the  parameter  list  property  of  the 
ADD-REFEREE  transaction  defines  a  complex  property: 

< (REFEREE, AUTHOR, EDITOR, PAPER) , add-referee , ADD-REFEEEE> 

Any  combination  of  specializations  of  the  classes  REFEREE,  AUTHOR, 
EDITOR,  and  PAPER  must  have  an  "add-referee"  complex  property  whose 
p-value  is  a  transaction  that  is  a  specialization  of  ADD-REFEREE.  For 
example,  the  "add- referee"  p-value  for,  say,  SCIENCE-REFEREE,  AUTHOR, 
SCIENCE-EDITOR,  and  SCIENCE-PAPER  must  have  at  least  the  properties  of 
ADD-REFEREE  and  possibly  more.  As  a  simple  specialization,  we  can 
ensure  that  scientific  papers  are  only  reviewed  by  science  referees  by 
specializing  the  "insert"  action  of  ADD-REFEREE  as  follows: 

action  insert. . a2. . a21  on 

— t^ClENC E-REFEREE, AUTHOR, SCIENCE-EDITOR, SCIENCE-PAPER) . . a dd-ref eree 
IS  insert-object  rflt  into  SCIENCE-REFLIST 
wlChlrfl^.  ref  eree< — -r^eree, 
rflt. author< — author , 
rflt. pa per < — paper) 

This  specialization  is  valid  only  if  "rflt"  has  been  specialized  as 
local  rflt  on 

— TRCIENCE-REFEREE, AUTHOR, SCIENCE-EDITOR , SCIENCE-PAPER) .. add-ref eree 
IS  SCIENCE-REFLIST 

and  all  of  SCIENCE-REFEREE,  SCIENCE-EDITOR,  SCIENCE-PAPER,  and 
SCIENCE-REFLIST  are  valid  specializations  of  REFEREE,  EDITOR,  PAPER, 
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and  REFLIST  respectively. 

The  above  specialization  illustrates  specialization  of 
non-boolean  expressions.  The  "insert"  action  property  of  the 
specialized  transaction  is  the  same  as  the  "insert"  action  property  of 
its  parent  class  except  that  its  "a21"  property  has  been  specialized 
to  insert  tokens  into  SCIENCS-EEFLIST  instead  of  just  fiEFLIST.  That 
is,  using  the  definitional  properties  and  the  definitional  property 
selector,  we  are  able  to  specialize  the  "insert"  property  by  simply 
specializing  the  desired  portion  of  it,  i.e.  "a21",  and  inheriting 
the  rest  of  it  intact  (without  the  need  to  restate  the  inherited 
part).  In  general,  for  two  non-boolean  expressions  E  and  E* ,  E*  IS-A 
E  if  and  only  if  E'  causes  at  least  the  side  effects  of  E  and  possibly 
more.  It  is  obvious  that  the  above  specialization  satisfies  this 
requirement,  since  doing  an  insertion  into  SCIENCE-REFLIST  also  causes 
an  insertion  to  be  done  into  REFLIST. 


Boolean  expressions  can  also  be  specialized.  Suppose,  for 
example,  that  we  wish  to  impose  the  constraint  that  the  maximum  number 
of  papers  a  science  referee  can  be  reviewing  at  any  one  time  is  7. 
Then  we  specialize  the  "paper- limit?"  condition  as  follows: 


preregs  paper-limit?  on 

“ITCTENCE-REFEREE, AUTHOR, SCIENCE-EDITOR , SCIENCE-PAPER) . . a  dd-referee 
is  referee. num-papers-refereeing  <  7 

exc  ILLEGAL-SCI-REF (r : ref eree , a : author , e: editor , p : paper) 


This  specialization  is  valid  because  the  new  ceiling  on 
"ref eree . nu m-papers-ref ereeing"  of  7  is  more  restrictive  than  the 
ceiling  of  10  imposed  earlier  for  ordinary  referees.  That  is,  in 
general,  for  two  boolean  expressions  E  and  E',  E*  IS-A  E  if  and  only 
if  E*  implies  E.  Obviously  "ref eree. num-papers-refereeing"  <  7 
implies  "ref eree. num-papers-refereeing"  <  10  and  so  this  requirement 
is  satisfied. 


The  exception  property  of  "paper-limit?"  given  above  has  been 
specialized  to  ILLEGAL-SCI-REF.  This  is  valid  only  if  ILLEGAL-SCI-REF 
is  a  specialization  of  ILLEGAL-REFEREE.  That  is: 


EXCEPTION-CLASS  ILLEGAL-SCI-REF  isa  ILLEGAL-REFEREE  with 
characteristics 
r ; HCTENCE-HEFER EE 
p: SCIENCE-PAPER 
end 

FIND-NEW-REF, 


The  exception  handler  for  ILLEGAL-REFEREE, 


should  be 
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specialized  to  contain  the  extra  details  relevant  to  replacing 

rejected  scientific  referees.  We  give  the  details  of  this 
specialization  in  the  next  section. 

As  mentioned  earlier,  not  only  can  a  transaction  (or  any  other 
class  for  that  matter)  be  refined  by  specializing  its  existing 
properties  but  also  new  properties  can  be  added.  For  instance, 

suppose  we  wish  to  enforce  the  constraint  that  the  referee* s  area  is 
the  same  as  the  author* s  area.  Then  we  add  the  new  prerequisite 
property: 

prereqs  same-area?  on 

■(^CTENCE-REFER  EE. 'SCIENCE-AOTHOE,  EDITOR, PAPER)  ..add-referee  is 
referee. area=autnor. area 

exc  INCOMPATIBLE-AREAS  (r:referee , a: author, p: paper) 

This  new  property,  of  course,  requires  that  the  exception  class 
INCOMPATIBLE-AREAS  and  its  exception  handlers  be  specified  elsewhere. 
In  addition,  all  transaction,  or  script  classes  that  use  ADD-REFEREE 
must  have  their  appropriate  calling  expressions  specialized  to  reflect 
the  newly  specified  exception  handlers. 

2. 4  Explicit  Versus  Implicit  Specialization 

The  type  of  specialization  illustrated  above  for  transactions  is 
called  implicit  specialization.  This  contrasts  with  the  explicit 
specialization  illustrated  earlier  for  the  data  classes.  Explicit 
specialization  of  a  class  requires  a  new  class  definition  to  have  an 
isa  clause  declaring  the  new  class  to  be  a  specialization  of  a 
previously  defined  class.  Implicit  specialization,  on  the  other  hand, 
associates  new  or  specialized  properties  with  an  existing  class  via 
the  class*  specialized  definitional  key  or  parameter  property  list. 
It  should  be  noted  that,  while  all  classes  in  TAXIS  can  be  specialized 
either  way  (keeping  in  the  TAXIS  spirit  of  treating  data  and 
procedural  classes  in  the  same  conceptual  framework) ,  the  specialized 
key  or  parameter  properties  used  in  an  implicit  specialization  must  be 
explicitly  specialized  elsewhere.  We  see  a  TAXIS  program  as  a 
hierarchy  of  explicitly  specialized  data  classes  in  conjunction  with  a 
matching  parallel  hierarchy  of  the  implicitly  specialized  procedural 
classes  that  use  these  data  classes.  For  example,  if  transaction  T 
has  data  class  C  as  one  of  its  parameters,  then  the  explicit 
specialization  of  C  to  C*  gives  rise  to  a  new  transaction  T*,  which  is 


Page  15 


a  specialization  of  T  and  has  parameter  C*. 

Implicit  specialization  of  procedural  classes  has  one  important 
advantage  over  explicit  specialization  of  those  same  classes:  when 
the  procedure  is  executed,  any  new  or  specialized  properties 
associated  with  it  through  its  parameter  definitional  property  are 
automatically  included  or  not  included  in  the  procedure's  execution 
depending  on  the  definitional  p- values  of  the  procedure's  arguments. 
For  example,  if  ADD-HEFEEEE  is  called  with  its  four  arguments  being 
instances  of  SCIENCE-REFEREE,  AUTHOR,  SCIENCE-EDITOR,  and 
SCIENCE-PAPER,  respectively,  then  the  specialized  "insert"  and 
"paper-limit"  properties  are  automatically  included  in  its  execution 
(but  the  new  "same-area?"  prereguisite  property  is  not).  However,  if 
its  arguments  are  instances  of  of  SCIENCE-REFEREE,  SCIENCE- AUTHOR, 
EDITOR,  and  PAPER,  respectively,  then  the  new  '*same-area?"  property  is 
automatically  included  in  the  transaction's  execution  (but  the 
specialized  "insert?"  and  "paper-limit?"  properties  are  not).  And 
finally,  if  the  transaction's  four  arguments  are  instances  of 
SCIENCE-REFEREE,  SCIENCE-AUTHOR,  SCIENCE-EDITOR,  and  SCIENCE-PAPER, 
then  all  three  of  the  properties  are  automatically  included  in  the 
transaction's  execution. 

Execution  of  explicitly  specialized  procedural  classes,  on  the 
other  hand,  requires  an  explicit  call  to  the  appropriate  class.  For 
example,  suppose  the  above  specializations  were  given  in  a  new 
transaction  ADD-SCI-REFEREE  which  was  declared  to  be  a  specialization 
of  ADD-REFEEEE.  Then  in  order  to  execute  these  specializations  while 
adding  referees  to  SCIENCS-REr LIST ,  we  would  have  to  call 
ADD-SCI-REFEREE  explicitly  rather  than  just  calling  ADD-REFEREE  with 
the  appropriately  specialized  arguments. 
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3  Designing  the  Pragmatic  Component  of  an  IIS 


1^1  Introduction  to  Scripts 

As  mentioned  before,  processes  involving  user/system  interaction 
are  represented  by  scripts.  Script  and  transition  classes  are 
incorporated  into  TAXIS  as  two  new  predefined  metaclasses.  A  script 
can  be  thought  of  as  a  known  plan  to  accomplish  some  goal.  Each 
script  is  represented  using  a  transition  net.  That  is,  a  script  is  a 
linked  set  of  states  that  form  one  or  more  paths,  some  of  which  may  be 
cycles.  The  decision  of  which  particular  path  to  follow  is  determined 
by  user  input  (i.e.  dialogue  acts)  and  the  current  state  of  the 
system,  making  scripts  both  event  and  data  driven. 

Because  IIS  applications  involve  potentially  many  users 
conducting  a  large  numbers  of  simultaneous  operations  on  a  database, 
it  is  desirable  that  instances  of  TAXIS  scripts  be  able  to  run 
concurrently.  As  a  result,  tools  are  needed  for  modelling  possible 
coordination  and  data  transfer  reguirements  between  script  instances. 
We  have  adopted  a  modified  form  of  Hoare*s  1/0  commands  for 
communicating  sequential  processes  [Hoare  78],  These  commands,  which 
we  call  inter-script  commands,  can  be  used  both  to  provide 
coordination  and  to  transfer  data  between  concurrently  running  script 
instances. 

The  script  formalism  used  to  model  processes  is  based  on  a 
simplified  version  of  Zisman’s  augmented  Petri  nets  [ Zisman  77],  As 
such,  scripts  provide  facilities  for  modelling  decision  making, 
concurrency,  and  synchronization. 

A  script  can  be  viewed  as  a  directed  graph  with  two  types  of 
nodes.  A  circular  {or  elliptical)  node  is  called  a  state  and  a  bar 
node  is  called  a  transition.  Each  transition  can  have  one  or  more 
input  states  {states  that  have  edges  directed  into  the  transition)  and 
one  or  more  output  states  {states  that  have  edges  directed  out  of  the 
transitioD) .  Similarly,  each  state  can  have  one  or  more  input 
transitions  {transitions  that  have  edges  directed  into  the  state)  and 
one  or  more  output  transitions  (transitions  that  have  edges  directed 
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out  of  the  state) .  Each  state  of  a  script  can  be  either  on  or  off 
(said  to  be  either  marked  or  unmarked)  .  If  all  the  input  states  of  a 
transition  are  marked,  then  the  transition  is  said  to  be  enabled.  An 
enabled  transition  may  fire.  The  firing  of  an  enabled  transition 
unmarks  each  of  the  input  states  and  marks  each  of  the  output  states. 
(A  currently  marked  state  that  is  remarked  as  a  result  of  a  transition 
firing  simply  remains  marked.)  The  firing  of  transitions  generally 
disables  some  transitions  and  enables  others. 

Decision  making  in  a  script  is  provided  for  by  a  state  having 
multiple  output  transitions.  Concurrency  can  be  expressed  by  a 
transition  having  multiple  output  states  while  synchronization  can  be 
expressed  either  as  a  transition  having  multiple  input  states  or  a 
state  having  multiple  input  transitions. 

Each  transition  in  a  script  has  a  set  of  conditions  and  a  set  of 
actions  associated  with  it  (*) .  An  enabled  transition  is  fired  after 
the  successful  execution  of  all  its  actions.  These  actions  are 
executed  only  if  all  its  conditions  have  been  evaluated  to  true 
beforehand.  If  all  the  conditions  of  an  enabled  transition  are  not 
currently  true  one  of  two  things  may  happen:  the  conditions  will 
become  true  at  some  later  time  or,  as  the  result  of  other  transitions 
firing,  the  transition  may  become  disabled.  The  set  of  enabled 
transitions  of  a  script  are  called  the  acti ve  transition  set .  The 
enabling  and  firing  of  transitions  changes  membership  in  this  set.  As 
such,  the  enabling  and  firing  of  transitions  represents  the  occurrence 
of  events.  Completion  of  these  events  may  require  communication  with 
outside  sources,  such  as  with  script  users  or  with  other  concurrently 
running  scripts.  These  types  of  communications  (i.e.  dialogue  acts 
and  inter-script  coordination  with  or  without  data  transfer)  are 
carried  out  as  actions  in  the  action  sets  associated  with  the 
transitions. 

1*.2  Script  Semantics 

Scripts  are  ’’transition”  based,  in  that  transition  descriptions 
make  up  the  body  of  a  script.  They  are  defined  in  the  usual  TAXIS 


{*)  Our  formalism  differs  from  [ Zisraan  77]  in  that  he  associates  one 
or  more  condition/action  pairs  with  each  transition  while  we  only 
associate. a  single  list  of  conditions  followed  by  a  single  list  or 
actions  with  each  transition. 
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manner  in  terms  of  classes  and  properties.  Script  classes  are  similar 
to  transaction  classes  in  that  they  have  parameters  and  locals 
property  categories,  but  differ  in  that  the  body  of  a  script  is 
composed  of  transition  properties  rather  than  action  properties.  To 
illustrate  the  concept  of  scripts  we  introduce  in  this  section  the 
coding  for  the  FIND-NEW-REF  script  exception  handler  mentioned 
earlier.  This  script  conducts  a  dialogue  with  the  editor,  informing 
him  of  the  circumstances  surrounding  the  referee's  rejection  and 
requesting  a  suitable  replacement.  Once  the  editor  has  supplied  a  new 
referee,  the  script  adds  him  to  the  referee  list  using  ADD^BEFEEEE  as 
before.  The  script  is  shown  on  diagram  2. 

Values  are  passed  to  a  script  instance  through  its  parameter  list 
property.  These  values  uniquely  identify  an  instance  of  that  script. 
Because  many  instances  of  a  script  can  exist  simultaneously,  their 
parameter  values  must  be  unique.  The  parameter  list  for  FIND-NEW-EEF 
is  given  as; 

SCRIPT-CLASS  FIND-NEW-REF  with 
parameters 

Tind^-new-ref ;  exc-parm 
This  sets  up  the  definitional  property: 

<ILLEGAL-REFEEEE,find-new-ref ,FIND-NEW-REF> 

Particular  instances  of  ILLEGAL-REFEREE  define  a  factual  property 
whose  p- value  is  the  current  execution  instance  of  FIND-NEW-REF. 

Local  properties  are  used  to  declare  all  the  local  variables  of  a 
script.  [Note  that  all  parameters  must  be  locals  also.)  Local 

variables  can  be  used  to  hold  either  values  for  computation  within  a 
script  or  to  act  as  its  states.  Scripts  (and  also  transactions)  do 
not  have  global  variables.  Global  data  can  be  accessed  from  variable 
classes,  through  the  script's  parameter  values,  or  via  inter-script 
communication.  State  variables,  whose  names  by  convention  are  the 
same  as  the  states  with  which  they  correspond  in  the  script's 

definition,  can  have  values  belonging  to  the  class  STATE  which  is 
restricted  to  values  'on'  and  'off.  If  a  state  variable  has  a  value 
of  'on'  then  that  state  is  said  to  be  marked;  if  it  has  a  value  of 
'off  then  it  is  said  to  be  unmarked.  A  state  variable  initially  has 

value  unklI2wn»  meaning  that  it  is  neither  marked  nor  unmarked.  When 
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determining  if  a  transition  is  enabled,  states  with  the  values  *off* 
and  unknown  are  treated  the  same,  i.e.  as  unmarked;  however  the 
distinction  between  the  two  values  has  important  consequences  when 
studying  the  past  execution  of  a  script-  Some  of  the  variables  that 
might  be  declared  in  the  local  property  category  of  FIND-NEW-EEF  are: 

locals 

“~§xc=parm:ILLEGAL-*EEFEEEE 
new- ref : REFEREE 

illegal-referee  default  *on',  editor-replied, 
have-new-ref : STATE 

The  "exc-parra"  property  serves  as  the  parameter  of  the  script.  The 
"new-ref"  property  is  a  local  variable  (which  by  defualt  initially  has 
value  unknown)  .  The  ”illegal-ref eree" ,  ’’editor-replied",  and 
•’have-new-ref"  properties  serve  as  the  states  in  the  script.  The 
STATE  class  is  a  finitely  defined  class  given  by: 

STATE:  =  {I  'on*  ,  ’off’  1} 

The  "illegal-referee"  state  is  initially  marked  (i.e.  has  default 
value  ’on’)  while  the  "editor-replied"  and  "have-new-ref"  are 
initially  neither  marked  nor  unmarked  (i.e.  have  value  unknown) . 

Each  transition  property  in  the  transition  category  corresponds 
directly  with  the  transition  of  the  same  name  in  the  script’s 
definition  (see  diagram  2) .  A  transition  property  has  a  transition 
class  instance  as  its  value.  Transition  classes  have  input,  output, 
conditions,  and  actions  property  categories.  The  input  and  output 
properties  of  a  transition  specify  the  input  and  output  states  of  that 
transition.  Condition  pfroperties  are  boolean  expressions  without  side 
effects  while  action  properties  are  non-boolean  expressions  with  side 
effects.  These  boolean  and  non-boolean  expressions  include  the  usual 
expressions  allowed  in  TAXIS  (see  [Mylopoulos  et  al  80]  and  [Wong  81]) 
as  well  as  additional  expressions  related  to  dialogue  and  inter-script 
communication. 

The  FIND-NEW-EEF  script  has  two  transition  properties  in  its 
transition  list  category.  The  first,  "tell-editor " ,  passes  the 
exception  data  to  the  editor  and  requests  a  new  referee  from  him.  The 
second,  "add-new-ref ",  inserts  that  referee  into  EEFLIST  using  the 
ADD-REFEREE  transaction. 
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transitions 
tell-editor : 

input  from : illegal-ref eree 
output  to : ed itor-replied 
actions 

ref-re  iec ted: s- inform  (exc-parm. e. code, exc- par ra.  r , 

exc-parm. a , exc-parm. p) 

get- new- ref : s-reguest  [exc-parm . e. code, new-ref ) 


add-new-ref : 

input  from: editor-replied 
output  to : ha ve-n ew-ref 
conditions 

“el-suppried-n ew-ref? : u-inf ormed [exc-parm.e. code, new- ref ) 
^tions 

Insef t-in-list : add-ref eree  (new-ref ,exc-parm. a , 

exc-parm.e , exc-parm.  p) 
exc-nandler  ehl  for  ILLEGAL-EEFEBEE 
Is~?TFU=!TE¥-HEF 
end  /*  transition  list  */ 


When  a  script  instance  is  first  created  (as  a  result  of  either  an 
instantiate  command  or  a  raised  exception) ,  the  active  transition  set 
is  determined  as  those  transitions  with  all  their  input  state 
properties  initially  having  value  *on*.  Since  "illegal-referee”  has 
default  value  ’on*  and  is  the  only  input  state  of  the  "tell-editor" 
transition,  that  transition  is  initially  the  only  transition  in  the 
active  transition  set.  Each  script  instance  has  an  interpreter 
instance  associated  with  it  which  executes  the  script  instance  by 
checking  and  rechecking  all  the  conditions  of  all  the  transitions  in 
the  active  transition  set.  When  a  set  of  conditions  belonging  to  an 
enabled  transition  are  found  to  be  true,  the  interpreter  stops 
condition  checking  and  executes  and  fires  that  transition.  Thus  the 
"tell-editor"  transition  is  immediately  executed  upon  instantiation  of 
the  FIND-NEW-REF  script  as  it  has  no  condition  properties  associated 
with  it,  i.e.  the  condition  true  is  assumed.  Once  a  transition  has 
been  executed  it  is  fired  by  assigning  the  value  *off*  to  all  input 
state  variables  and  the  value  *on*  to  all  output  state  variables. 
This  usually  results  in  removing  some  transitions  from  the  active 
transition  set  and  replacing  them  with  others.  Firing  the 
"tell-editor"  transition  [after  its  successful  execution)  results  in 
the  removal  of  that  transition  from  FIND-NEW-REF*s  active  transition 
set  and  the  addition  of  the  "add-new-ref"  transition  in  its  place. 
Condition  checking  is  now  resumed  on  the  new  active  transition  set. 
This  execution  and  firing  cycle  for  the  transitions  of  a  script 
continues  until  either  the  script  instance  is  explicitly  terminated 
using  a  terminate  command  or  is  implicitly  terminated  by  an  empty 
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active  transition  set.  The  FIND-NEW-REF  script  is  implicitly 
terminated  once  the  ’’add-new-ref ”  transition  fires  as  at  this  time  its 
active  transition  set  is  empty.  It  should  be  noted  that  condition 
sets  in  the  active  transition  set  are  continually  checked  and 
rechecked  even  if  none  of  them  are  presently  true  (♦).  They  may  later 
become  true  as  the  result  of  some  dialogue  act,  inter-script 
communication,  or  timing  event.  This  is  in  constrast  to  ordinary 
production  systems  which  stop  execution  if  either  one  of  the  actions 
of  an  executing  rule  is  to  stop  or  none  of  the  rules  are  currently 
true . 

A  transition  is  executed  by  executing  all  its  action  properties 
in  sequential  order.  The  execution  of  the  " tell-editor ”  transition 
thus  involves  executing  its  ”ref-re jected"  and  "get-new-ref ”  action 
properties.  The  "ref-rejected"  action  uses  an  s-inform  command  to 
pass  the  "r",  "a",  and  "p"  p-values  of  FIND-NEW-REF * s  exception 
instance  argument  (representing  referee,  author,  and  paper  exception 
information  respectively)  to  the  editor's  terminal,  identified  by  his 
code.  The  "get-n ew-ref "  action,  on  the  other  hand,  simply  requests 
the  same  editor  to  supply  a  new  referee.  Execution  of  the 
"add-new-ref "  transition  can  proceed  only  if  its 
"ed-supplied-new-re f ?"  condition  has  been  evaluated  to  true.  This 
condition  checks  if  the  editor  has  indeed  supplied  a  new  referee  to 
the  script  instance  in  response  to  the  s-request  command.  The  editor 
can  supply  such  a  value  by  using  a  u-inform  command  to  supply  values 
to  new-ref's  properies,  i.e. 

u-inform  (exc-parm. f ind-new-r ef ,new-ref . name< — "some  name", 

^  ne w-ref . address< — "some  address", 

new-r ef . phone< — "some  phone  number",...) 

The  first  argument  of  this  command  uniquely  identifies  the 
FIND-NEW-REF  script  instance  via  its  parameter  factual  p-values.  The 
remaining  arguments  of  the  command  supply  actual  values  to  the 
"new-ref"  local  property  of  that  script  instance.  The 
"insert-in-list"  action  of  the  "add-new-ref"  transition  calls  the 
ADD-REFEREE  transaction  with  the  new  referee  value  as  one  of  its 


(*)  The  order  and  rate  at  which  enabled  transitions  are,  checked  in 
some  script  is  undetermined.  We  assume  that  the  firing  order  of 
several  simultaneously  transitions  is  unimportant;  if  this  is  not  the 
case  then  the  desired  order  can  be  built  into  the  script's  definition. 
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arguments.  It  is  interesting  to  note  that  this  script  specifies 
itself  as  the  exception  handler  for  the  ILLEGAL-REFEREE  exception 
class  that  may  be  raised  during  A DD-REFEREE* s  execution.  This  means 
that  a  potentially  infinite  number  of  FIND-NEW-REF  instances  may  be 
created,  one  for  each  of  a  series  of  rejected  referees. 

Because  of  the  cyclic  nature  of  the  condition  checking  in  a 
script  instance,  scripts  can  "live”  for  long  periods  of  time.  For 
example,  script  instances  that  monitor  the  actions  of  either  an  editor 
or  a  referee  during  the  review  of  a  paper  for  publication  in  some 
journal  can  realistically  run  for  several  months  or  longer.  Because 
of  this,  we  can  examine  the  factual  properties  of  a  script  in  much  the 
same  way  as  we  retrieve  data  from  a  relation.  For  example,  we  can 
retrieve  the  referee,  author,  and  paper  information  for  all  unresolved 
ILLEGAL-REFEREE  exceptions  being  handled  by  joe-editor  (via  the 
FIND-NEW-REF  script)  in  the  following  manner: 

for  script-instance  in  FIND-NEW-REF 

where  script-instance. exc-parra. e  =  joe-editor  do 

s-Inf orm (joe-editor. code, script-instance . exc-parm.  r , 

scr ipt- instance. e  xc-parm. a , script- instance. exc-parm. p) 

Of  course,  "script- instance"  must  be  declared  as  a  local  variable  in 
the  script  using  it,  i.e.  "script-instance"  must  have  FIND-NEW-REF  as 
its  definitional  p-value.  This  is  so  "script-instance"  can  have 
instances  of  FIND-NEW-REF  as  its  factual  p-values. 

We  can  also  examine  the  factual  p-values  of  a  script's  local 
properties.  For  example,  to  determine  the  execution  status  of  an 
instance  of  FIND-NEW-REF  we  can  use  an  u-reguest  command  to  examine 
that  script's  state  properties: 

u-request  (exc-parm. f ind-new-ref , illegal- referee, 
editor-replied ,have-new-ref) 

If  this  command  returned  values  'off,  'on',  and  unknown  respectively 
for  the  three  state  properties  "illegal-referee",  "editor-replied", 
and  "have-n ew-ref "  then  we  would  know  that  the  first  transition 
"tell-ed itor"  has  successfully  fired  but  that  the  second  transition 
"add-n ew-ref "  has  not  yet  fired  (most  likely  because  the  editor  has 
not  yet  supplied  a  new  referee  value) .  The  factual  p-value  of  any 
condition  or  action  property  of  a  script  is  always  nothing,  i.e.  it 
is  undefined. 
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1-.3  A  Script  Specialization  Example 

Since  exception  handlers  are  specified  as  complex  properties  with 
an  expression  class  and  an  exception  class  .  as  its  subjects, 
specializations  of  these  subjects  can  be  used  to  designate 
specializations  of  the  exception  handler.  For  example,  suppose  we 
wish  to  specialize  FIND-NEW-REF  to  prevent  the  editor  from 
re-specifying  a  referee  who  has  previously  caused  an  instance  of 
ILLEGAL-SCI-REF  to  be  raised  for  that  paper.  We  can  do  this  by 
inserting  each  exception  token  (representing  data  about  a  raised 
exception)  into  a  variable  class  REJECTED-REFS  and  then  checking  that 
any  new  referee  is  not  in  this  class*  extension.  If  a  newly  supplied 
referee  token  is  in  REJECTED-REFS  then  the  editor  is  informed  of  this 
and  asked  to  supply  another  referee  token  in  its  place. 

First,  we  add  an  extra  action  to  the  ”tel  1-editor*'  transition  to 
save  the  current  exception  token,  i.e.  the  script's  only  argument,  in 
REJECTED-REFS; 

action  tell-editor. .save-re jected-ref  on 
ICATLER. .  add,  ILLEGAL-SCI-REF)  .  .ehl  i^ 
insert-object  rejected-ref  into  REJECTED-REFS 
wiCETrejecfed-ref .r< — exc-parm. r , 
regected-ref . a< — exc-parm. a , 
rejected- ref .  e<--exc-^parm.  e  , 
regected-ref . p<--exc-parm.  p) 

This  specialization  is  valid  only  if  the  "rejected-ref"  variable  has 
been  added  as  a  local  property  of  the  specialized  script. 


Next,  we  add  a  condition  to  the  "add-new-ref "  transition 
checks  that  the  new  referee  has  not  been  previously  rejected. 


that 


condition  add-new-ref .. not-rejected?  on 
— TCATIER. . add , ILLEGAL-SCI-REF)  .  .  eh  1  Is 
[begin 
locals 

— SkTBOOLEAN 
actions 

aT:ok  <--  true 

a2;for  rejecled-ref  in  REJECTED-REF  do 
If  ( (re j ected-ref . r  =  new-ref) 

and  (re jected-ref . a  =  exc-parm. a 
an3  [re jected-ref .  e  =  exc-parm.  e) 
anH  ,‘r  egected-ref .  p  =  exc-parm.  pi  ) 
then  ok  false 

returns 
rin: ok 

end) 


This  condition  ensures  that  the  ADD-REFEREE  transaction  will  not  be 
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called  for  a  previously  rejected  referee  (associated  with  a  particular 
author,  editor,  and  paper)  as  such  a  call  will  result  in  an  instance 
of  the  exception  IL LEGAI-SCI-EEF  being  raised  again. 


Finally,  we  specify  a  new  transition  ’'rejected-referee”  which 
tells  the  editor  the  referee  has  been  previously  rejected  and  asks  for 
a  new  referee  again. 


transition  rejected-referee  on 

7CJ'IIE'R7.  add,ILLEGAL-SCI-R'ET)  .  .  ehl  is 
input  from: editor-replied 
output  to : editor-replied 
conditions 

rejected?:  rejected-ref  instance-of  REJECTED-REFS 
where (re jected-ret. r=new-ref ) 
and  fre jected-ref . a=exc-parm. a 
and (rejected-ref . e=exc-parm . ei 
and  (rejected-ref. p=exc-parm. p) ) 
actions  ^ 

re t-f eject ed-be fore :  s-inf orm  (exc-parm. code. e, exc-parm. r , 
exc-parra. a, exc-parm. p, "previously  rejected  referee") 
ask- new -ref -a gain :  s-reguest (exc-parm. e. code, new-ref) 
end 


Now,  any  time  a  call  to  ADD-REFEREE  in  the  CALLER  transaction  results 
in  an  instance  of  ILLEGAL-SCI-EEF  being  raised  (say  via  the 
specialized  "paper-limit?"  condition)  the  new  condition,  action,  and 
transition  properties  specified  above  are  automatically  included  in 
the  specialized  FIND-NEK-REF  script  handling  the  exception.  (Once  the 
circumstances  surrounding  the  exception  have  been  resolved,  all 
exception  tokens  in  REJECTED-REFS  for  the  paper  should  be  removed.) 
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4  A  Journal  Editing  Example 

!iil  Procedure 

The  example  presented  here  is  based  on  a  modified  version  of 
Zisman*s  journal  editing  procedure  as  outlined  in  chapter  6  of  [Zisraan 
77].  Basically,  the  process  of  publishing  a  paper  in  a  journal 
requires  the  journal's  editor  to  appoint  one  or  more  referees  to 
review  the  paper.  The  referees  each  submit  a  report  to  the  editor  on 
the  suitability  of  the  paper  appearing  in  that  journal.  The  editor 
uses  these  reports  to  make  a  decision  of  accept,  reject,  or  revise. 
Each  editor  decision  of  revise  requires  the  referees  to  submit  new 
reports  on  the  revised  paper.  The  process  concludes  when  the  editor 
makes  a  decision  of  accept  or  reject.  We  use  two  scripts  to  model 
this  procedure;  one  for  the  editor's  actions  and  one  for  each  of  the 
referee's  actions.  Each  time  a  paper  enters  into  the  system,  an 
instance  of  the  editor  script  and  one  or  more  instances  of  the  referee 
script  are  used  to  monitor  the  activities  of  the  editor  and  the 
various  referees  for  that  paper. 

The  editor  script,  EDITOE-KET,  is  shown  in  diagram  3.  Once  a 
paper  arrives,  the  editor  must  designate  one  or  more  referees.  Each 
time  a  week  expires  and  he  has  failed  to  do  so,  the  system  sends  a 
reminder  to  him.  Once  the  referees  have  been  designated,  an  instance 
of  the  referee  script  is  created  for  each  referee.  If  one  or  more  of 
the  referees  should  refuse  to  review  the  paper,  the  editor  is  required 
to  find  replacements.  Each  time  a  week  passes  in  which  the  editor 
hasn't  yet  designated  new  referees  to  replace  any  refusing  referees 
results  in  the  system  sending  a  reminder  to  this  effect  to  the  editor. 
Referee  script  instances  are  created  for  all  new  referees.  Once  all 
proposed  referees  have  agreed  to  review  the  paper,  the  editor  waits 
for  their  reports.  After  the  editor  has  received  all  these  reports  he 
must  make  his  decision  within  two  weeks;  otherwise  the  system  sends 
him  a  reminder  for  his  overdue  decision  every  two  weeks  until  he  has 
made  it.  If,  on  the  one  hand,  the  editor's  decision  calls  for  a 
revision  of  the  paper,  the  author  is  informed  of  this  and  the  editor 
awaits  the  revision.  Once  the  revised  paper  is  received,  it  is  passed 
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to  each  of  the  referees  and  their  new  reports  are  awaited.  When  the 
editor  receives  these  reports  he  must  again  make  a  decision  regarding 
the  suitability  of  the  paper  for  publication.  If,  on  the  other  hand, 
the  editor* s  decision  is  to  accept  or  to  reject  then  the  author  is 
informed  of  the  decision  and  the  editor  and  referee  script  instances 
are  terminated.  At  any  time  after  the  editor  receives  a  paper  right 
up  until  the  time  the  editor  has  made  a  decision  of  either  accept  or 
reject,  the  author  has  the  option  to  withdraw  his  paper,  in  which  case 
the  editor  and  referee  script  instances  are  terminated. 

The  referee  script,  REFEREE-NET,  is  shown  in  diagram  4.  Once  an 
instance  of  the  referee  script  has  been  created  for  a  proposed 
referee,  the  referee  is  asked  for  his  consent.  If  his  reply  is  no, 
then  this  fact  is  communicated  to  the  editor  script  and  the  referee 
script  instance  is  terminated.  Each  time  a  two  week  period  passes 
with  no  reply  from  the  proposed  referee  the  system  sends  a  reminder  to 
that  referee.  If  the  proposed  referee *s  reply  is  yes  than  his  report 
is  awaited.  Again,  each  two  week  period  that  passes  without  the 
editor  having  received  the  referee's  report  causes  the  system  to  send 
that  referee  a  reminder.  Once  the  referee's  report  has  been  received 
and  this  fact  has  been  communicated  to  the  editor  script,  the  referee 
script  waits  for  the  possibility  that  the  editor's  decision  may  be  to 
revise  (in  which  case  a  revised  paper  should  be  forthcoming).  If  the 
editor's  decision  is  to  accept  or  to  reject  then  the  editor  script 
terminates  all  instances  of  the  referee  script  as  well  as  itself. 

Hi.!  i.k§.  §2^  Referee  Scripts 

The  complete  EDITOR-NET  and  REFEREE-NET  scripts  are  given  in 
[  Barron  80].  We  present  only  fragments  here  to  illustrate  the-  various 
features  of  scripts. 

Each  time  a  paper  is  submitted  for  publication,  the  editor  (or 
his  secretary)  creates  an  instance  of  EDITOR-NET  for  it.  The  first 
transition  of  this  script,  "paper-arri ves" ,  conducts  a  dialogue  with 
the  author  and  the  editor;  informing  the  author  of  the  paper's 
receipt  and  of  his  option  to  withdraw  it  at  any  time  and  requesting 
the  editor  to  supply  one  or  more  referees  to  review  the  paper. 
Consider  the  coding  of  the  this  transition; 
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REFEP£E-NET 


diagram  4 
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pa per-ar rives: 

input  from: waiting-paper 

output  to: (waiting-ref-names, waiting-paper- withdrawn) 
actions 

paper-received:  paper-received  < —  true 
tell- author :  s-inform (author. code , paper- received) 
paper-withdr  awn7:  c;-T'orrnoc:-|-  f;^n  +  V.r»T' na  T^ciT'- IJT  4- 1 

get-ref-names: 


7:  s-request  (author .code, paper- withdrawn) 
askTeditor. code , not  (nothing  = 

(get-obiect  rfTt  in  FTTLIST 


SiTere 

and 

and 

a  1 l-ref-names-submitted7: _ _ _ 

set- wait-ref-tirae:  ref-time  ^ —  current-time 


(rnt. editor  =  editor) 
rflt. author  =  author) 
rflt. paper  =  paper)))) 

s-request  (editor . code, all-re f-names-in) 


end , 


The  only  input  state,  "waiting-paper"  of  the  transition  is  the 
only  state  variable  initialized  to  value  *on'  in  the  local  properties 
of  the  script.  This  means  that  initially  the  "paper-arri ves" 
transition  is  the  only  enabled  transition  in  the  script.  Since  it 
does  not  have  any  condition  properties  (the  default  condition  true  is 
assumed)  its  action  properties  are  executed  seguentially  and  it  is 
fired.  Firing  of  this  transition  marks  the  " waiting-paper- withdrawn" 
and  "waiting-ref-names"  states  and  unmarks  the  "waiting-paper"  state. 
The  effect  of  this  is  that  three  transitions,  "paper- with  drawn" , 
"have-referees",  and  "ref-na mes-late" ,  are  enabled  and  the 
"paper-ar rives"  transition  is  disabled.  It  is  interesting  to  note 
that  the  "paper-withdrawn"  transition  will  remain  enabled  until  it  is 
either  fired  or  the  script  is  terminated.  This  allows  the  author  to 
withdraw  his  paper  anytime  before  the  editing  procedure  has  been 
completed. 

The  s-inform,  s-request ,  and  ask  commands  in  the  action 
properties  are  examples  of  a  script  performing  dialogue  acts.  If  we 
assume  that  a  user’s  code  is  simply  his  name  then 

s-inform  (joe-author, paper-received) 


informs  the  user  identified  by  code,  joe-author,  of  the  value  of  the 
"paper-received"  property,  i.e.  it  informs  the  author  that  his  paper 
has  been  received  (if  the  value  of  "paper-received"  is  truie)  . 
Simila  rly 

§i:£g2.ii6st  (joe-author, paper- withdrawn) 

reguests  joe-author  to  supply  a  value  of  paper- withdrawn  (if  he 
wishes).  To  respond  to  that  request  the  author  may  execute  a  u-inf orm 
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command.  For  example  if  joe-author  desires  to  withdraw  his  paper  he 
can  execute 

u-inform  [  (i oe-editor , joe-author , paper  1) . editor-ner , 
pdper-withdrawn<— true) 

The  first  argument  of  any  uzillfoH  must  uniquely  identify  the  script 
instance;  the  remaining  arguments  must  be  name/value  pairs.  Two 
points  should  be  kept  in  mind  about  s-reguest  commands.  First,  the 
execution  of  any  s-reguest  simply  passes  the  request  for  data  to  the 
appropriate  users;  it  does  not  require  that  the  requested  data  be 
supplied  at  any  time  in  the  future.  Thus  an  author  submitting  a  paper 
for  publication  can  withdraw  it  from  consideration  at  any  time  by 
simply  using  an  u-inform  to  assign  the  value  true  to 
•'paper-withdrawn”.  If  the  author  never  wishes  to  withdraw  his  paper 
he  can  simply  do  nothing  or  he  can  assign  a  value  of  false  to 
"paper-withdrawn”  using  a  u-inform  command.  (It  should  be  noted  that 
if  he  assigns  false  to  "paper- withdrawn”  the  s-reguest  command  for 
that  value  is  finished,  i.e.  the  author  cannot  later  withdraw  his 
paper  by  reassigning  true  to  "paper- withdrawn” ) .  Second,  an  s-reguest 
command  must  be  executed  for  any  variable  that  is  supplied  a  value  by 
a  u-inform  command.  This  ensures  the  script's  "integrity”  by 
maintaining  an  orderly  dialogue  between  a  script  and  its  users. 
Without  this  condition,  a  user  could  arbitrarily  assign  (and 
re-assign)  values  to  a  script's  variables  without  any  regard  to  the 
effect  this  might  have  on  the  script's  execution. 

A  user  may  examine  the  values  of  any  of  a  script's  variables 
during  its  lifetime  by  using  a  u-reguest  command.  Its  form  is  the 
same  as  an  s-reguest  command  except  that  its  first  argument  identifies 
a  script  instance  rather  than  a  script  user.  For  example 

liI.£6£U6St  ( (joe-editor,  joe-author,  paper  1)  .  .  editor-net , paper,  title) 

will  return  the  title  of  the  paper  written  by  joe-author  (which  is 
represented  by  token  paper  1)  that  is  being  considered  for  publication 
by  joe-editor. 

The  ask  command  is  used  by  a  script  to  ask  a  user  to  perform  an 
action.  The  first  argument  identifies  a  user  while  the  remaining 
arguments  are  boolean  expressions.  If  a  boolean  expression  is  true 
the  ask  command  does  nothing.  However,  if  it  is  false,  the  expression 
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is  passed  to  the  user  who  may  make  it  true.  There  is  no  requirement 
that  the  user  actually  make  this  expression  true.  To  ensure  that  he 
does,  the  script  must  make  an  explicit  check  at  some  later  time.  The 
ask  command  in  the  above  transition  checks  if  the  lEFLIST  relation  has 
any  referees  that  have  been  assigned  to  review  the  author's  paper.  If 
not,  the  editor  is  asked  to  insert  some  referees  in  the  relation  for 
that  author  (as  a  way  of  making  the  passed  expression  true) .  No  means 
are  provided  for  the  editor  to  directly  do  such  an  insertion;  instead 
he  must  use  some  previously  defined  script.  This  script  would  conduct 
dialogue  with  the  editor  to  obtain  referees  and  use  the  ADD-EEFEREE 
transaction  to  insert  each  referee  in  EEFLIST.  (As  such,  this  script 
would  be  very  similar  to  FIND-NEW-EEF. )  The  use  of  such  a  script  is 
necessary  so  that  control  can  be  maintained  by  the  system  as  to  who 
performs  what  operations  on  the  database  (and  with  what  data) .  Once 
the  editor  has  designated  the  desired  number  of  referees  he  uses  a 
u-inform  command  to  assign  value  true  to  the  "all-ref-names-in"  local 
variable  in  the  editor  script. 

It  should  be  noted  that  the  actual  manner  in  which  a  dialogue 
command  is  performed  depends  on  whether  or  not  the  user  has  direct 
contact  with  the  system.  Dialogue  witli  direct  users  (for  example,  the 
editor)  can  be  performed  directly  on  terminals-  Dialogue  with 
indirect  users  (for  example,  authors  and  referees)  might  be  conducted 
by  mail  or  telephone  with  perha|)s  a  secretary  (who  is  a  direct  user) 
acting  as  the  interface. 

To  gain  information  about  dialogue  previously  conducted,  we  have 
five  predicates:  one  for  each  of  the  five  dialogue  commands  discussed 
above.  For  example 

u-inf ormed ( joe-author , paper- withdrawn) 

returns  true  if  the  author  has  performed  a  u-inform  command  supplying 
a  value  for  "paper-withdrawn"  and  false  otherwise.  In  general,  a 
u-informed  predicate  checks  if  the  user  named  as  its  first  argument 
has  executed  one  or  more  u-inform  commands  supplying  values  to  the 
rest  of  the  predicate's  arguments.  The  other  four  predicates: 
u-reguested,  s-informed,  s-requested,  and  asked  work  in  much  the  same 
way  as  u-informed,  but  instead  check  if  appropriate  u-reguest, 
s-inform,  s-reguest,  and  ask  command  (s)  have  been  previously  executed. 
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Arjother  interesting  transition  is  the  ”have-r ef erees"  transition. 
This  transition  checks  if  referees  have  been  proposed  to  review  the 
author's  paper  and,  if  so,  it  creates  an  instance  of  REFEBEE-NET  to 
monitor  the  activities  of  each  such  referee. 


have— ref erees: 

input:  from: waiting-ref-names 
output:  to: waiting-ref-replies 

conditions 

'air- rets- in ? :  a  11-ref-names-in  = 


actions 

starts-refs:  for 


true 


rflt  in  EEELIST 


end 


^ere  nr  fit.  editor  =  editor) 

'and  rflt.  author  =  author) 
and  Ir fit.  paper  =  paper) )  do 

instantiate  REFEBEE-NET (teferee, author , editor , paper) 


The  ”all-ref-names-in"  variable's  value  is  set  by  a  u-inform  command 
which  should  be  executed  by  the  editor  after  he  has  inserted  the 
proposed  referees  in  EEFLIST.  The  for  statement  in  the  "start-refs" 
action  property  creates  an  instance  of  REFEREE-NET  for  each  proposed 
referee  in  EEFLIST  satisfying  the  where  clause  conditions. 


The  first  task  of  each  REFEREE-NET  script  instance  is  to  obtain 
the  referee's  consent  to  review  the  paper.  Regardless  of  whether  the 
answer  is  yes  or  no,  each  referee's  answer  must  be  communicated  to  the 
editor  script.  This  type  of  communication  is  accomplished  by  a  set  of 
inter-script  commands  based  on  Hoare's  primitive  I/O  commands  for 
communicating  sequential  processes  [ Hoare  78].  The  give  and  take 
commands  are  used  to  transfer  data  between  concurrently  running  script 
instances.  Before  these  commands  can  transfer  data  they  must 
correspond  [Hoare  78].  Two  inter-script  commands  correspond  if: 

1)  the  take  command  in  the  script  receiving  data,  the  destination 
script,  identifies  another  script  instance  as  its  source, 

2)  the  give  command  of  that  other  script  instance,  the  source 
script,  specifies  as  its  destination  script  the  name  of  the  first 
script,  and 

3)  the  attributes  of  the  take  command  match  the  arguments  of  the 
give  command  in  the  order  they  appear. 

Corresponding  inter-script  commands  are  executed  simultaneously 
and  the  valuers)  in  the  give  command  are  assigned  to  the  identifier  (s) 
in  the  take  command.  A  give  command  fails,  i.e.  produces  an 
execution  error,  if,  in  attempting  to  execute  it,  the  appropriate 
destination  script  instance  doesn't  exist  or  if  any  of  the  values  it 
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is  to  transfer  are  undefined  (have  value  unknown).  Similarly,  a  take 
command  fails  if,  in  attempting  to  execute  it,  the  appropriate  source 
script  doesn't  exist.  Since  give  and  take  commands  require 
synchronization  before  they  can  be  simultaneously  executed,  whenever 
an  inter-script  command  is  encountered,  it  must  wait  for  a 
corresponding  inter-script  command  to  be  encountered  before  any  data 
transfer  occurs.  As  a  result  of  this,  corresponding  inter-script 
commands  can  be  used  to  coordinate  the  execution  of  concurrently 
running  script  instances.  It  is  also  possible  to  model  "pure" 
coordination  (i.e.  just  synchronization  without  any  data  transfer)  by 
simply  passing  an  empty  list  of  values  in  corresponding  give  and  take 
commands. 

To  avoid  failure  of  inter-script  commands  and  to  obtain 
information  about  the  present  and  past  state  of  inter-script 
communication,  we  have  four  inter-script  predicates.  A  giving  or 
taking  predicate  returns  true  if,  upon  execution,  a  matching  give  or 
take  command  is  waiting  in  the  named  script;  otherwise  false  is 
returned.  In  a  similar  fashion,  a  gave  or  a  took  predicate  will 
return  true  if,  upon  execution,  a  matching  give  or  take  command  has 
been  successfully  executed  in  the  named  script;  otherwise  false  is 
returned.  It  is  possible  that  a  particular  inter-script  command  (or 
for  that  matter,  a  dialogue  command)  can  have  been  executed  two  or 
more  times  in  the  past  in  a  particular  script  instance.  This  poses  no 
problems  as  a  predicate  checks  for  only  one  successful  completion  of 
the  appropriate  command (s). 

As  an  example  of  inter-script  communication  consider  the  scenario 
where  all  proposed  referees  agree  to  review  the  author's  paper.  Two 
transitions,  "referees-all-agree"  in  EDITCE-NET  and  "ref eree-accepts" 
in  REFEREE-NET  are  used  to  carry  out  this  communication  (and 
coordination) .  The  coding  of  the  two  transitions  are  given  below. 

referee s-al 1-agree; 

input  from:  waiting-ref-replies 
output  to:  waiting-reports 
condition s 

aTr-reI§-agr ee? :  /*  This  condition  is  true  only  if  all 
proposed  referees  agree  to  review  the  paper.  */ 

(begin  locals 

agree:  BOOLEAN 
actions 

“'aTT  agree  < —  true 
a2:  for  rflt  in'FEFLIST 

where  f  (rfXt. editor  =  editor) 
an5  (rflt. author  =  author) 
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and  (rf  It .  paper  =  paper)  )  do 

( Irf It.  ref  eree ,  author,  editor, 
paperf- refer ee-net, reply : YES)  =  false 
then  begin 

a71:  agree  < —  false 
a 2 2 :  exit 
end 

returns 

rTn:  agree 
end)  =  true 
actions 

taKe-rep lies ;  for  rflt  in  EEFLISl 

where  f  [rfX^. editor  =  editor) 
and  (rflt. author  =  author) 
and jrf It . paper  =  paper) ) do 

taXeJ (rflt. referee, author , editor , paper) . referee-net, 
reply :  Y ES) 

end ; 


referee- accepts: 

inout  from:  waiting-ref-reply 
output  to:  waiting-ref-report 
conditions 

fef-acce pts? :  ref-reply  =  *yes* 
actions 

telT-editor :  s- in  form  (edit or . code, ref eree, ref-reply) 
tell-editor-net :  give  ( (editor , author , paper)  . editor-net , ref- reply) 
set-time:  report-time  <; —  current- time 

ask- f or-report:  s-reguest (referee. code, report-submitted) 
set-no-wai ts:  no-wa it^report s  < —  1 
end : 


The  "all-ref  s-agree '•  condition  of  the  first  transition  is  a  compound 
boolean  expression  which  returns  true  if  all  referee  script  instances 
monitoring  a  particular  author*s  paper  are  currently  ready  to  execute 
a  give  command  with  the  editor  script  and  false  otherwise.  Note  that 
the  giving  predicate  only  returns  true  or  false  depending  on  whether 
or  not  the  named  script  instance  has  a  matching  give  command  waiting; 
it  does  not  do  the  actual  data  transfer.  For  this,  we  must  execute  a 
set  of  corresponding  give  and  take  commands.  That  is 


bahe  { (rflt. ref eree , author ,ed itor, paper) . referee-net, reply : YES) 


in  the  "take-replies"  property  of  the  "ref erees-all-agree"  transition 
corresponds  with  the  "tell-editor-net"  property 


( (editor ,  author  ,  paper)  .  editor-net ,  ref-reply) 


in  the  "ref eree- accepts"  transition.  Execution  of  these  two  commands 
cause  the  value  of  ref-reply  in  the  referee  script  to  be  assigned  to 
reply  in  the  editor  script  (provided  ref-reply  has  a  value  of  type 
YES) .  The  exit  statement  of  "a22"  is  an  efficiency  consideration 
only.  The  first  time  the  giving  predicate  of  ”a2"  evaluates  to  false 
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the  "all-ref s-agree?"  compound  condition  is  guaranteed 
false,  regardless  of  whether  or  not  all  other  unchecked 
instances  are  waiting  with  corresponding  give  comman 
"all-ref s-agree? "  as  soon  as  its  value  can  be  determi 
checking  of  all  other  script  instances  for  correspondin 
can  be  avoided. 


It  should  be  n 
condition  of  the 
referee  script  ins 
waiting  for  the 
reason  exists  for 
commands  can  be 
reguirement.  Corre 
similar  types 
"referee-refusal"  a 
the  "all-reports-i 
and  RSFEEEE-NET  scr 


oted  that  the  construction  of  the  " 
"ref erees-all-agree"  transition  m 
tances  must  have  a  corresponding 
condition  to  be  evaluated  to  true. 

doing  things  this  way;  in  fac 
used  to  model  just  about  any  type 
spending  give  and  take  commands  are 
of  coordination  requirements 
nd  the  "referee-refuses"  transition 
n"  and  "report-made"  transitions  in 
ipts . 


4£.3  The  IS-A  Relationship  for  Scripts 


to  evaluate  to 
referee  script 
ds.  By  exiting 
ned,  redundant 
g  give  commands 

a 11-refs- agree" 
eans  that  all 
give  command 
No  particular 
t  inter-script 
of  coordination 
used  to  model 
between  the 
s  and  between 
the  EDITOR-NET 


IS-A  hierarchies  of  scripts  are  defined  in  much  the  same  way  as 
for  transactions,  i.e.  implicitly  via  specialized  parameter 
properties.  As  a  simple  example  of  IS-A  for  scripts  consider 
specializing  the  "have-referees"  transition  of  EDITOR-NET  to  include  a 
new  condition  ensuring  at  least  2  referees  with  expertise  in  the 
paper's  area  have  been  designated  for  all  scientific  papers. 


transition  have-referees  on 
— t^nTTaT[7AUTH0R  , SCIENCE-PIPER) 
conditions 

af-Teast- 2-refs ?:  [begin 
locals 

— count: INTEGER 
actions 


editor-net 


'aT:  count  < —  0 
a2:  for  rflt  in 


wEere 
anE 
anf[ 
anE 
CO  unf 
returns 

rfnl  count 
end)  =  true 


SCIENCE-EEFLIST 


(rflE.  editor  =  editor) 
rflt. author  =  author) 
rflt. paper  =  paper) 
paper. area  instance-gf 
< —  count  +  T 

>=  2 


is 


rflt. ref eree. area)  )  do 


This  new  condition  checks  that  two  or  more  referees  have  been  assigned 
to  review  the  paper  by  counting  the  number  of  appropriate  instances  in 
SCIENCE-REFLIST.  The  "paper. area  instance-of  rflt. ref eree. area" 
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condition  ensures  that  the  area  of  the  paper  matches  one  of  the 
referee’s  areas.  (Hemember  that  the  "area"  property  of  EEFEHEE  was 
declared  using  se t-of .  meaning  that  it  can  have  one  or  more  p-values 
at  the  same  time.)  Of  course,  the  "ail-refs-in?'*  condition  is 
inherited  intact  and  both  conditions  must  now  be  true  before  the 
transition  can  be  executed  and  fired  in  the  specialized  script. 


A  more  interesting  specialization  of  EDITOE-NET  would  require 
that  the  editor  be  informed  of  all  referees  late  with  their  reports. 
This  can  be  accomplished  by  adding  a  new  transition  to  EDITOE-NET  as 
follows: 


transition  ref-reports^late  on 

“"T^CTEN’CE-EDITOP^SCIENCE-ADTTTOR, PAPER)  .  .editor-net  is 
input  f  rom :  waitin  g-report 
output  to : wai ting-report 
conditions 

Time-exceeded?:  (current-time  -  report-time)  >  "2  weeks" 
actions 

tell-ed-rpts: for  rflt  in  SCIENCE-RFFLIST 

wEere f (rf It. editor  =  editor) 
fnd  frflt  .author  =  author) 
and (rflt. paper  =  paper) do 
if  (giving  I  (rflt. ref eree, editor .author , 

paper) . f eleree-net . report-in : T ROE) 
then  s-inf orm (editor. code, rflt. referee, 
rllt. author ,rf It . paper , "report  late" ) 
wait-again:  report-time  < —  current-time 

end 


This  transition  is  an  example  of  a  timing  event  in  that  every  2  weeks 
the  editor  receives  a  list  of  all  referee  information  for  referees  who 
have  not  yet  submitted  their  report.  (He  is  responsible  for  taking 
some  action  to  resolve  each  referee’s  tardiness).  This  list  is 
compiled  by  checking  for  all  appropriate  REFEREE-NET  instances  that 
are  not  waiting  to  communicate  a  value  of  true  to  EDITOE-NET.  The 
"report- time"  local  variable  has  to  be  initialized  to  the  current  time 
before  the  "ref-reports-late"  transition  first  becomes  enabled.  This 
is  done  by  specializing  the  proceeding  "ref erees-all-agree "  transition 
as  follows: 


action  set-wait-time  on  (SCIENCE-EDITOR. 

TETHOR, SClENCE-PAPERf . .editor- net. . ref erees-all-agree  is 
report-time  <--  current-time 


Now,  whenever  the  "waiting-reports"  state  is  marked  (as  a  result  of 
the  "referees-all-agree  transition  firing)  both  the  "all-reports-in" 
and  the  new  "ref-reports-late"  transition  will  be  enabled.  The 
"ref-reports-late"  transition  will  continually  execute  and  fire  at  2 
week  intervals  until  the  "all-reports-in"  transition  is  executed  and 
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fired;  in  which  case  *‘ref-reports-lat e"  becomes  disabled. 

As  a  last  specialization  example  we  wish  to  allow  referees  who 
have  initially  agreed  to  review  a  paper  to  later  be  able  to  renege  on 
their  commitment.  This  involves  adding  a  new  transition  to  each  of 
the  scripts.  The  new  transition  in  REFEEEE-NET,  "ref -backs-out" , 
allows  the  referee  to  inform  the  system  that  he  is  unable  to  review 
the  paper  for  some  reason.  The  editor  is  informed  of  this  through 
inter-script  communication.  The  new  transition  in  EDITOR-NET, 
"reguire-new-ref ” ,  upon  receipt  of  this  communication,  passes  the 
information  to  the  editor  and  waits  for  him  to  propose  a  new  referee. 
The  first  transition  can  be  given  as  follows; 

transition  ref-backs-out  on 

TSCTETTC'E-REFER  EE,  ADTH0R7EDIT0R,  SCIENCE-PAPER)  ..referee-net  is 
input  from: waiting-ref-report 
toiref-quits 
conditions 

Backouf?;  backout  =  'yes* 
actions 

comm- wit h-ed ;  3 ive ( (editor ,author . paper) . editor-net, backout) 
kill-script:  terminate  referee-net 
end  ^ 

The  execution  of  this  transition  achieves  two  things.  First,  the 
"comm-wit h-ed"  action  informs  the  editor  of  the  referee's  decision  to 
renege  on  his  commitment  by  way  of  inter-script  communication  with  the 
editor  script.  Second,  the  "kill-script"  action  removes  the  reneging 
referee's  script  instance  from  REFEREE-NET 's  extension  by  using  an 
explicit  terminate  command.  This  transition  requires  that  "ref-guits" 
and  "backout"  be  added  as  local  variables  in  the  specialized  script. 
The  "ref-quits"  variable  serves  as  a  new  state  in  the  specialized 
referee  script.  To  allow  the  referee  to  assign  a  value  to  "backout" 
requires  that  a  s-request  command  be  executed  for  it  before  the 
"ref-backs-out"  transition  becomes  enabled.  This  can  be  done  by 
adding  a  new  action  to  the  preceding  "r ef eree-accepts"  transition  of 
the  referee  script; 

action  backout-option  on  [SCIENCE-REFEREE, 

^THOR ,  EDITOR,  SCI  ENCE- PAPER)  • .  referee-net. .  ref  eree-accepts  is 
s-request  (ref eree. code, backout) 

The  " require-new-ref ”  transition  to  be  added  to  EDITOR-NET  can  now  be 
specified  as; 
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transition  reguire-new-ref "  on 
■[riTT'rairTAOTHOH,  SCIENCE- PA 
conditions 
“  rer-Eaclcing-out ?:  [begin 
locals 

Eaclcing-out :  BOOLEAN  default 
actions 

OTTor  rflt  in  HEFLIST 


editor-net  is 


false 


wHere  frflE. editor  =  editor) 
and  [rflt. author  =  author) 
and  (rf It . paper  =  paper)) do 

if  alving  [  (rflt.  referee  ,auF’dor, editor, paper)  •  referee -net 
bacI^utiYES)  =  true 
then  begin 

aT1  :  backing-out  < —  true 

a  1 2  :  exit 

end 

returns" 

"rFnT  backing-out 
end)  =  true 
action^ 

for  rflt  in  SCIENCE-EEFLIST 
^ere  f  (rf  TF.  edit  or  =  editor) 

"and  (rflt. author  =  author) 
and  (rflt . paper  =  paper) )  do 
giving  ( (rflt. referee, auFhor, editor, 

"  paper7« ref eree-ne t , 
backout : YES) do 
begin 

^ •  take  ( (rf It. referee , author , editor , 
paper) . referee-net, backout :YES) 
a2:  s-inf orm (editor. code, rflt. referee, author , 
paperTFackout) 

s-reguest  (editor. code, new-ref s-names-in) 
delete-ob gect  rflt  in  SCIENCE-EEFLIST 


process-comm 


end 


a3 : 
a4 : 
end 


The  "ref-backing-out?"  condition  of  this  transition  is  a  compound 
property  that  checks  if  at  least  one  referee  is  declining  to  review  a 
paper.  If  this  is  case,  the  ”process-comm"  action  property  is 
executed.  This  compound  action  consists  of  four  actions, 
'*process-comm. .  a  1"  to  "process-comm. .  a4”  ,  that  are  performed  for  each 
referee  reneging  on  his  commitment.  First,  the  interscript 
communicator  between  the  editor  and  referee  scripts  is  completed 
(allowing  the  referee  script  instance  to  terminate).  Then,  the  editor 
is  informed  of  the  referee’s  decision  to  back  out.  Next,  the  editor 
is  requested  to  supply  a  new  referee  to  replace  the  old  referee.  And 
finally,  the  "rflt"  token  for  the  declining  referee  is  deleted  from 
SCIENCE-EEFLIST. 


The  firing  of  this  transition  changes  the  execution  of  EDITOE-NET 
in  an  interesting  way.  That  is,  the  script  "backs  up"  by  treating  the 
situation  of  a  referee  reneging  on  his  commitment  to  review  a  paper  in 
the  same  way  as  if  the  referee  had  initially  refused  to  review  the 
paper.  Thus,  once  all  reneging  referees  have  been  replaced  (i. e.  the 
"have-new-ref s"  transition  has  fired)  the  "ref erees-all-agree"  and 
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•'referee-refusal"  transitions  become  re-enabled  and  execution  of  the 
script  continues  in  the  usual  way. 

It  may  not  be  clear  from  the  rather  simple  IS-A  examples 
presented  in  this  paper  that  IS-A  is  a  powerful  tool  for  organizing 
detail.  More  complex  examples  that  illustrate  this  require  much  more 
space  than  this  paper  permits.  However,  to  gain  an  idea  of  the  power 
of  IS-A  as  a  program  design  principle  consider  a  possible  IS-A 
hierarchy  of  TAXIS  classes  for  the  journal  editing  procedure.  At  the 
most  general  level  we  define  editor  and  referee  scripts  that  monitor 
the  actions  that  are  common  to  all  editors  and  referees.  A  more 
specialized  level  could  incorporate  the  actions  unique  to  the 
different  academic  categories,  say,  arts  and  science.  Further 
specializations  would  take  into  account  the  peculiarities  of  the 
different  academic  categories,  for  example,  computer  scientists, 
physicists,  or  historians.  Of  course,  at  each  level  of 
specialization,  various  data  and  transaction  classes  would  be  added  or 
specialized,  as  needed  by  the  specialized  scripts.  Because  at  each 
level  of  specialization,  only  new  knowledge  that  is  relevant  to  that 
level  is  added  (with  the  more  general  knowledge  inherited  according  to 
the  features  of  the  IS-A  relationship) ,  it  Is  significantly  easier  to 
capture  the  large  amounts  of  detail  that  are  characteristic  of  IISs. 
In  other  words,  at  each  specialization  level,  a  TAXIS  programmer  need 
concern  himself  only  with  the  details  that  distinguish  that  level  from 
more  general  ones.  This  makes  IS-A  a  powerful  design  mechanism  for 
IIS  programs. 
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5  Conclusion 


5.  1  Concluding  Remarks 

We  have  described  in  this  paper  an  extension  to  TAXIS  which 
allows  the  designer  of  an  IIS  to  describe  within  one  conceptual 
framework  a  database,  the  application  programs  that  operate  on  it,  and 
the  dialogues  to  be  supported  by  the  IIS  for  I/O.  Our  proposal 
assumes  that  software  development  costs  will  be  reduced,  not  by 
decoupling  the  design  of  user  interfaces  from  that  of  the  database  and 
its  application  programs,  but  by  offering  design  tools  which  allow  a 
parallel  design  of  all  components  of  an  IIS,  from  its  database  to  its 
application  programs  to  its  user  interface. 

5. 2  Further  Research 

The  work  described  in  this  paper  constitutes  only  a  part  of  the 
TAXIS  project.  Scripts,  as  described  above,  provide  facilities  for 
the  definition  of  the  pragmatic  aspects  of  a  user  interface  for  an 
IIS.  The  syntactic  aspects  of  a  user  interface  (which  would  be  used 
to  specify  the  actual  form  of  I/O  messages)  has  yet  to  be  designed. 
We  see  this  component  being  added  to  TAXIS  within  the  existing 
framework  of  classes,  properties,  and  the  IS-A  relationship.  Once  the 
design  of  TAXIS  is  complete,  a  TAXIS  compiler  will  be  written  to  test 
the  language.  Such  an  implementation  is  expected  to  require  the 
solution  of  such  problems  as  the  mapping  of  IS-A  hierarchies  of  data, 
transaction,  and  script  classes  into  relations,  procedures,  and 
production  systems  respectively.  Another  important  problem  we  intend 
to  address  in  the  future  involves  studying  the  usefulness  of  TAXIS  to 
particular  application  areas  such  as  inventory  control  or  airline 
reservations.  [  Di  narco  81]  is  currently  designing  a  TAXIS  program  to 
keep  track  of  pacemaker  patients  at  the  Toronto  General  Hospital. 
This  program  should  eliminate  some  of  the  serious  problems  of  the 
existing  FORTRAN  system,  for  example,  the  lack  of  portability  between 
hospitals  even  though  they  have  similar  requirements,  the  manual 
integrity  checking  now  done  on  all  data  before  it  is  entered,  and  the 
rigid  user/system  interface.  We  expect  TAXIS  to  contribute 
substantially  to  the  solution  of  these  problems  by  providing  highly 
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sharable  "packages”  of  data  and  procedural  classes,  by  doing  automatic 
prerequisite  checking  on  all  data  entered,  and  by  using  scripts  to 
provide  a  more  flexible  user  environment.  Such  research  may  also 
provide  some  insight  into  such  questions  as  how  good  is  a  design 
methodology  based  on  IS-A  and  in  what  order  should  the  classes  of  a 
TAXIS  program  be  designed. 
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AN  APL  TERMINAL  APPROACH  TO  COMPUTER  MAPPING 
R.  Kvaternik,  December  1972 
[M.Sc,  Thesis,  DCS.  1972] 

AN  IMPLEMENTATION  LANGUAGE  FOR  MINICOMPUTERS 
G.G.  Kalmar,  Januaiw  1973 
[M.Sc.  Thesis,  DCS.  1972] 

COMPILER  STRUG  PURE 

W.M.  McKceman,  January  1973 

[Proceed ing.s  of  l.hc  USA-Jnf)an  Computer  Confereruu:,  1972j 
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*  C.SRC-24 

CSRG-25 

*  CSRG-26 

*  CSRG-27 

»  CSRG-28 

*  CSRG-29 

*  CSRG-30 

CSRG-31 

CSRG-32 

■*<  CSRG-33 

»  CSRG-34 

CSRG-35 

’*•  CSRG-3G 

^  CSRG-37 


AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER  PROGRAM 
ENGINEERING 

J.D.  Gannon  (ed.),  March  1973 

THE  INVESTIGATION  OF  SERVICE  TIME  DISTRIBUTIONS 
Eleanor  A.  Lester,  April  1973 
^  [M.Sc.  Thesis.  DCS,  1973] 

PSYCHOLOGICAL  COMPLEXITi  OF  COMPUTER  PROGRAMS: 

AN  INITIAl.  EXPERIMENT 
Larry  Weissman,  August  1973 

STRUCTURED  SUBSETS  OF  THE  PL./l  LANGUAGE 

Richard  C.  Holt  and  David  B.  Wortman,  October  1973 

ON  REDUCED  MATRIX  REPRESENTATION  OF  LR(k) 

PARSER  TABLES 

Marc  fjouis  Joliat,  October  1973 

[Ph.D.  Thesis.  EE  1973] 

A  STUDENT  PROJECT  FOR  AN  OPERATING  SYSTEMS  COURSE 
B.  Czarnik  and  D.  Tsichrilzis  (eds.),  November  1973 

A  PSEUDO-MACHINE  tVK  CODE  GENERATION 
'''  Henry  John  Pasko,  December  1973 
[M.Sc.  Thesis,  DCS  1973] 

AN  ANNOTAED  BIBLIOGRAPHY  ON  COMPUTER  PROGRAM  ENGINEERING 
J.D.  Gannon  (ed.),  Second  Edition,  March  1974 

SCHEDULING  MULTIPLE  RESOURCE  COMPUTER  SYSTEMS 

E. D.  Lazowska,  May  1974 
[M.Sc.  Thesis.  DCS.  1974] 

AN  EDUCATIONAL  DATA  BASE  MANAGEMENT  SYSTEM 

F.  Lochovsky  and  D.  Tsichritzis,  May  1974 
[INFOR,  14(3).  PP.270-27B.  1976] 

ALLOCATING  STORAGE  IN  HIERARCHICAL  DATA  BASES 
P.  Bernstein  and  D.  Tsichritzis,  May  1974 
[Information  Systems  Journal,  v.l,  pp.  133- 140] 

ON  IMPLEMENTATION  OF  REI.ATIONS 
D.  Tsichrilzis,  May  1974 

SIX  PL/I  COMPILERS 

D.B.  Wortman,  P.J.  Khaiat,  and  D.M.  I.asker,  August  1974 
[Software  Practice  and  Evporienea,  v.8,  n.3. 

Juiy-Sept.  1976] 

A  METHODOLOGY  FOR  STUDYING  THE  PSYCHO], OGICAL  COMPI.EXITY 
01’  COMl-'UTEK  PROGiCAMS 
Laurence  M.  Wcissmnn,  August  1974 
[Ph.D.  Thesis.  DCS.  1974] 


CSRG-38  AN  INVESTIGATION  OF  A  NEW  METHOD  OF  CONSTRUCTING  SOFTW’-ARE 
David  M.  Lasker,  September  1974 
[M.Sc.  Thesis,  DCS,  1974] 

CSRG-39  AN  ALGEBRAIC  MODEL  FOR  STRING  PATTERNS 
Glenn  F.  Stewart,  September  1974 
>  [M.Sc,  Thesis,  DCS,  1974] 

CSRG-40  EDUCATIONAL  DATA  BASE  SYSTEM  USER’S  MANUAL 
J.  KlebanofT,  F.  Lochovsky,  A.  Rozitis,  and 

D.  Tsichritzis,  September  1974 

CSRG-41  NOTES  FROM  A  WORKSHOP  ON  THE  ATTAINMENT  OF 
RELIABLE  SOFTWARE 

David  B.  Wortman  (ed.).  September  1974 

CSRG-42  THE  PROJECT  SUE  SYSTEM  LANGUAGE  REFERENCE  MANUAL 
B.L.  Clark  and  F.J.B.  Ham,  September  1974 

C3RG-43  A  DATA  BASE  PROCESSOR 

E. A.  Ozknrnhan,  S.A.  Schn.st.er  and  K.C.  Smith, 

November  1974  [Proceedings  National  Computer- 
Conference  1975,  V.44,  pp. 379-300] 

CSRG-44  MATCHING  PROGRAM  AND  DATA  REPRESENTATION  TO  A 
COMPUTING  ENVIRONMENT 
Eric  C.R.  Hehner,  Nov'emver  1974 
[Ph.D.  Thesis,  DCS.  1974] 

Sec  Computer,  Vol.9,  No. 9,  August  1976,  pp. 65-70. 

CSRG-45  THREE  APPROACHES  TO  RELIABLE  SOFTWARE;  LANGUAGE  DESIGN, 
DYADIC  SPECIFICATIONS,  COMPLEMENTARY  SEMANTICS 
J.E.  Dorrahue,  J.D.  Gannon,  J.V.  GuLtag  and 
J.J.  Horning,  December  1974 

CSRG-46  THE  SYNTHESIS  OF  OPTIMAL  DECISION  TREES  FROM 
DECISION  TABLES 

Helmut  Schumacher,  December  1974 

[M.Sc.  Thesis,  DCS,  1974;  CACM,  v.  19,  n.6,  June  1976] 

CSRG-47  LANGUAGE  DESIGN  TO  ENHANCE  PROGRAMMING  RELIABILITY 
John  D.  Gannon,  January  1975 
[Ph.D.  Thesis.  DCS.  1975] 

CSRG-45  DETERMINISTIC  LEFT  TO  RIGHT  PARSING 

Christopher  J.M.  Turnbull.  -January  1975 
[Ph.D.  Thesis,  EE.  1974] 

CSRG-49  A  NETWORK  FRAMEWORK  FOR  RELATIONAL  IMPLEMENTATION 
D.  Tsichritzis,  February  1975  [in  Data  Base  Description, 

Dongue  and  Nijssen  (eds.).  North  Holland  Publi.shing  Co.] 


CSRG-50  A  UNIFIED  APPROACH  TO  FUNCTIONAL  DEPENDENCIES 
AND  REUTIONS 

P.A.  Bernstein,  J.R.  Swenson  and  D.C.  Tsichritzis 
February  1975  [Proceedings  of  the  ACM  SIGMOD 
Conference,  1975] 

CSRG-51  ZETA:  A  PROTOTYPE  RELATIONAL  DATA  RASE  MANAGEMENT  SYSTEM 
M.  Rrodie  (ed).  February  1975  [Proceedings  Pacific  ACM 
Conference.  1975] 

CSRG-52  AUTOMATIC  GENEPvATION  OF  SYNTAX-REPAIRING  AND 
PARAGRAPHING  PARSERS 
David  T.  Barnard.  March  1975 
[M.Sc.  Thesis,  DCS,  1975] 

CSRG-53  QUERY  EXECUTION  AND  INDEX  SELECTION  FOR  RELAT10NA.L 
DATA  BASES 

J.K.  Gillcs  Farley  and  Stewart  A.  Schuster,  March  1975 

CSRG-54  AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER  PROGRAM 
ENGINEERING 

J.V.  Guttag  (ed.),  Third  Edition,  April  1975 

CSRG-55  STRUCTURED  SUBSETS  OF  THE  PL/1  l.ANGUAGE 

Richard  C.  Holt  and  David  R.  Wortinan,  May  1975 

CSRG-58  FEATURES  OF  A  CONCEPTUAL  SCHEMA 

D.  Tsichritzis.  June  1975  [Proceedings  Very  Large 
Data  Base  Conference,  1975] 

CSRG-57  MERLIN:  TOWARDS  AN  IDEAL  PROGRAMMING  LANGUAGE 
Eric  C.R.  Hehner,  July  1975 

see  Acta  Informatica  Col.  10,  No. 3,  pp. 229-243,  1978 


CSRG-58  ON  THE  SEMANTICS  OF  THE  RELATIONAL  DATA  MODEL 
Kans  Albrecht  Schmid  and  J.  Richard  Swenson. 

July  1975  [Proceedings  of  the  ACM  SIGMOD  Conference.  1975] 


CSRG-59  THE  SPECIFICATION  AND  APPLICATION  TO  PKUGK^MMING 
OF  ABSTRACT  DATA  TYPES 
John  V.  Gntlag,  September  1975 
[Ph.D.  Thesis,  DCS.  1975] 


CSRG-00  NORM.ALIZATION  AND  FUNCTIONAL  DEPENDENCIES  IN  THE 


RELATIONAL  DATA  BASE  MODEL 


Phillip  Alan  Bernstein,  October  1975 
[Ph.D.  Thesis.  DCS.  1975] 


CSRG-61 


LSL:  A  LINK  AND  SEI.ECTION  I.ANGUAGE 

D.  Tsichritzis,  November  1975  [Proceedings  ACM 
SIGMOD  Confcrcnco,  1070] 
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CSRG-62  COMPLEMENTARY  DEFINITIONS  OF  PROGRAMMING  LANGUAGE 
SEMANTICS 

James  E.  Donahue.  November  1975 
[Ph.D.  Thesis,  DCS.  1975] 

CSRG-63  AN  EXPERIMENTAL  EVALUATION  OF  CHESS  PLAYING  HEURISTICS 
Lazio  Sugar,  December  1975 
[M.Sc.  Thesis.  DCS.  1975] 

CSRG-64  A  VIRTUAL  MEMORY  SYSTEM  FOR  A  RELATIONAL  ASSOCIATIVE 
PROCESSOR 

S.A.  Schuster,  E.A,  Ozkarahan,  and  K.C.  Smith, 

February  1976  [Proceedings  National  Computer 
Conference  1976,  v.45,  pp. 855-862] 

CSRG-65  PERFORMANCE  EVALUATION  OF  A  PiELATIONAL  ASSOCIATIVE 
PROCESSOR 

E.A.  Ozkarahan,  S.A.  Schuster,  and  K.C.  Sevcik, 

February  1976  [ACM  Transactions  on  Database 
Systems,  v.  1,  n;4,  December  1976] 

CSRG-66  EDITING  COMPUTER  ANIMATED  FILM 
Michael  D.  Tilson,  February  1976 
[M.Sc.  Thesis.  DCS,  1975] 

CSRG-67  A  DIAGRAMMATIC  APPROACH  TO  PROGRAMMING  LANGUAGE 
SEM.ANTICS 

James  R.  Cordy,  .March  1976 
[M.Sc.  Thesis,  DCS,  1976] 

CSRG-68  A  SYNTHETIC  ENGLISH  QUERY  LANGUAGE  FOR  A  RELATIONAL 
ASSOCIATIVE  PROCESSOR 

L.  Kerschberg,  E.A.  Ozkarahan,  and  J.E.S.  Pacheco. 

April  1976 

CSRG-89  AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER  PROGRAM 
ENGINEERING 

D.  Barnard  and  D,  Thompson  (eds.).  Fourth  Edition, 

May  1976 

’  CSRG-70  A  TAXONOMY  OF  DATA  MODELS 

L.  Kerschberg.  A.  Klug.  and  D.Tsichritzis,  May  1976 
[Proceedings  Very  Large  Data  Rase  Conference,  1976] 

^  CSRG-71  OPTIMIZATION  FEATURES  FOR  THE  ARCHITECTURE  OF  A 
DATA  BASE  MACHINE 

E. A.  Ozkarahan  and  K.C.  Sevcik,  May  1976 

[ACM  Transactions  of  Database  Systems,  v.2,  n.4,  December  1977] 

CSRG-72  THE  RELATIONAL  DATA  BASE  SYSTEM  OMEGA  -  PROGRESS  REPORT 
H.A.  Schmid  (ed.).  P.A.  Beriislein  (ed.),  13.  Arlow, 

R.  Baker  and  S.  Puzguj,  July  1976 
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CSRG-73 

CSRG-74 

^  CSRG-75 

CSRG-76 

CSRG-77 

♦  CSRG-78 

CSRG-79 

CSRG-80 

♦  CSRG-81 

CSRG-S2 

CSRG-83 

CSRG-B4 


CSRG-85 


AN  ALGORITHMIC  APPROACH  TO  NORMALIZATION  OF 
REIJ^TIONAL  DATA  BASF  SCHFUAS 
P.A.  Bernstein  and  C.  Beeri,  September  1976 

A  HIGH-LEVEL  MACHINE-ORIENTED  ASSEMBLER  LANGUAGE 
FOR  A  DATA  BASE  MACHINE 
^  E.A.  Ozkarahan  and  S.A.  Schuster,  October  1976 

DO  CONSIDERED  OD:  A  CONTRIBUTION  TO  THE  PROGRAMMING 
CALCULUS 

Eric  C.R.  Hehner,  November  1976 
Acta  Informatica  to  appear  1979 

SOFTWARE  HUT:  A  COMPUTER  PROGRAM  ENGINEERING 
PROJECT  IN  THE  FORM  OF  A  GAME 
J.J.  Horning  and  D.B.  tVortman,  November  1976 

[IEEE  Transactions  on  Soft%varc  Engineering,  v.SE-3,  n.4,  July  1977] 

A  SHORT  STUDY  OF  PROGRAM  AND  MEMORY  POLICY  BEHAVIOUR 

C.  Scott  Graham,  January  1977 

A  PANACHE  OF  DBMS  IDEAS 

D.  Tsichrilzis  (ed.),  Febi'uary  1977 

THE  DESIGN  AND  IMPLEMENTATION  OF  AN  ADVANCED  LALR 
PARSE  TABLE  CONSTRUCTOR 
David  H.  Thompson,  April  1977 
[M.Sc.^Ihesis,  DCS,  1976] 

AN  ANNOTATED  BIBLIOGRAPHY  ON  COMPUTER  PROGRAM 
ENGINEEFUNG 

D.  Barnard  (ed.),  Fifth  Edition.  May  1977 

PROGRAMMING  METHODOLOGY:  AN  ANNOTATED  DIDL10G17APHY 
FOR  IFIP  WORKING  CROUP  2.3 

''  Sol  J.  Greenspan  and  J.J.  Horning  (eds.).  First  Edition,  May  1977 
NOTES  ON  EUCLID 

edited  by  W.  David  Elliott  and  David  T.  Barnard,  August  1977 

TOPICS  IN  QUEUEING  NETWORK  MODELING 
edited  by  G.  Scott  Graham,  July  1977 

TOWARD  PROGRAM  ILLUSTRATION 
Edward  Yarwood,  September  1977 
[M.Sc.  Thesis,  DCS,  1974] 

CHARACTERIZING  SERVICE  TIME  AND  RESPONSE  TIME 

DISTRIBUTIONS  IN  QUEUEING  NETWORK  MODELS  OF  COMPUTER 
SYSTEMS 

Edward  D.  Lazowsku,  September  1977 
[Ph.D.  Thesis,  DCS.  1977] 
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CSRG-B6  MEASUREMENTS  OF  COMPUTER  SYSTEMS  FOR  QUEUEING 
NETTVORK  MODELS 
Martin  G.  Kienzle,  October  1977 

[M.Sc.  Thesis.  DCS,  1977;  Proc.  Int.  Symp.  on  Modelling  and  Performance 
Evaluation  of  Computer  Systems.  Vienna,  1979] 

CSRG-87  ’OLGA’  LANGUAGE  REFERENCE  MAN'UAL 

B.  Abourbih,  H.  Trickey,  D.M.  Lewis.  E.S.  Lee, 

P.I.P.  Boulton,  November  1977 

*  CSRG-8B  USING  A  GRAMMATICAL  FORMALISM  AS  A  PROGRAMMING  LANGUAGE 

Brad  A.  Silverberg,  January  1970 
[M.Sc.  Thesis,  DCS.  1973] 

CSRG-B9  ON  THE  IMPLEMENTATION  OF  RELATIONS;  A  KEY  TO  EFFICIENCY 
Joachim  W.  Schmidt.  January  1978 

CSRG-90  DATA  BASE  MANAGEMENT  SYSTEM  USER  PERFORMANCE 
Frederick  H.  Lochovsky,  April  1973 
[Ph-D.  Thesis.  DCS.  1978] 

CSRG-91  SPECIFICATION  AND  VERIFICATION  OF  DATA  BASE 
SEMANTIC  INTEGRITY 
Michael  LawTence  Brodie,  April  1978 
V  [Ph.D.  Thesis.  DCS,  1978] 

CSRG-92  STRUCTURED  SOUND  SYNTHESIS  PROJECT  (SSSP); 

AN  INTRODUCTION 

by  William  Buxton,  Guy  Fcdorkow,  with  Ronald  Bacckcr, 

Gustav  Ciamaga,  Leslie  Mezei  and  K.C.  Smith,  June  1978 

^  CSRG-93  ADEVICE-INDEPENDENT.GENERAL-PURPOSE  GRAPHICS  SYSTEM 
IN  A  MINICOMPUTER  TIME-SHARING  ENVIRONMENT 
William  T.  Reeves,  August  1978 
[M.Sc.  Thesis,  DCS,  1976] 

CSRG-94  ON  THE  AXIOMATIC  VERIFICATION  OF 
CONCURRE NT  ALG ORITKMS 
Christian  Lengauer,  August  1978 
[M.Sc.  Thesis,  DCS.  1978] 

CSRG-95  PISA-  A  PROGRAMMING  SYSTEM  FOR  INTERACTIVE 
PRODUCTION  OF  APPLICATION  SuFTW.ARE 
Rudolf  Marty,  August  1978 

CSRG~96  ADAPTIVE  MICROPROGRAMMING  AND  PROCESSOR  MODELING 
Walter  G.  Rosocha 
[Ph.D.  Thesis,  EE.  August  1978] 

*  CSRG-97  DESIGN  ISSUES  IN  THE  FOUNDATION  OF  A  COMPUTER-BASED 

TOOL  FOR  MUSIC  COMPOSITION 
William  Buxton 

[M.Sc.  Tlic^;ls,  CSRG,  October  1971)] 
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CSRG-98  THEORY  OF  DATABASE  MAPPINGS 
Anthony  C.  Klug 

[Ph.D.  Thesis,  DCS,  December  1978] 

CSRG-99  HIERARCHICAL  COROUTINES:  A  MECHANISM  FOR  IMPROVED 
PROGRAM  STRUCTURE 
r  Leonard  I.  Vanek,  February  1979 

CSRG-lOO' TOPICS  IN  PERFORMANCE  EVALUATION 
G.  ScoLt  Graham  (ed.).  ^Inly  1979 

C3RG-101  A  PANACHE  OF  DBMS  IDEAS  II 

F.H.  Lochovsky  (ed.).  May  1979 

CSRG-102  A  SIMPLE  SET  THEORY  FOR  COMPUTING  SCIENCE 
,  Eric  C.R.  Hehner,  May  1979 

CSRG-103  THE  CENTRALIZED  ALGORITHM  IN  DISTRIBUTED  SYSTEMS 
Ernest  J.H.  Chang 
[Ph.D.  Thesis,  DCS.  July  1979] 

CSRG-104  ELIMINATING  THE  VARIABLE  FROM  DIJKSTRA’S 
MINI-LANGUAGE 
D.  Hugh  Redelmeier,  July  1979 

« 

CSRG-105  A  LANGUAGE  FACILITY  FOR  DESIGNING  INTEIUCTIVE 
DATABASE-INTENSIVE  APPLICATIONS 
John  Mylopoulos.  Philip  A.  Bernstein.  Harr]'-  K.T.  Wong, 
July  1979 

CSRG-106  ON  APPROXIMATE  SOLUTION  TECHNIQUES  FOR 

QUEUEING  NETWORK  MODELS  OF  COMPUTER  SYSTEMS 
Satish  Kumar  Tripathi,  July  1979 

CSRG-107  A  FRAMEWORK  FOR  VISUAl,  MOTION  UNDERSTANDING 
John  K.  Tsotaos,  John  Mylopoulos,  H.  Doniiiuc  Covvey 
Steven  W.  Zucker,  DCS.  June  1979 

CSRG-108  DIALOGUE  ORGANIZATION  AND  STRUCTURE  FOR 
INTERACTIVE  INFORMATION  SYSTEMS 
John  Leonard  Barron 
[M.Sc.  Thesis,  DCS,  1900] 

*  CSRG-109  A  UNIFYING  MODEL  OF  PHYSICAL  DATABASES 
D.S.  Datory,  C.C.  Gotlieb,  April  1980 

CSRG-110  OPTIMAL  FILE  DESIGNS  AND  REORGANIZATION  POINTS 
D.S.  Batory,  April  1930 

CSRG-111  A  PANACHE  OF  DBMS  IDEAS  III 
D.  Tsichritzi.s  (ed.),  April  1980 
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CSRG-112  TOPICS  IN  PSN  -  II:  EXCEPTIONAL  CONDITION 

HANDLING  IN  PSN;  REPRESENTING  PROGRAMS  IN  PSN; 
CONTENTS  IN  PSN 

Yves  Lesperance,  Byran  M.  Kramer,  Peter  F.  Schneider 
April,  1980 

CSRG-113  SYSTEM-ORIENTED  MACRO-SCHEDULING 
C.C.  Gotlicb  and  A.  Schonbach 
May  1980 

CSRG-1 14  A  FRAMEWORK  FOR  VISUAL  MOTION  UNDERSTANDING 
John  Konstantins  Tsolsos 
[Ph.D.  Thesis,  DCS,  June  1980] 

CSRG-1 15  SPECIFICATION  OF  CONCURRENT  EUCLID 
James  R.  Cordy  and  Richard  C.  Holt 
July  1980 

CSRG-1 16  THE  REPRESENTATION  OF  PROGRAMS  IN  THE 

PROCEDURAL  SEI.LVNTIC  NETY/ORK  FORMALISM 

Bryan  M.  Kramer 

[M.S  c.  Thesis,  DCS,  1980] 

CSRG-1 17  CONTEXT-FREE  GRAMMARS  AND  DERIVATION  TREES  AS 
PR0GRM4M1NG  TOOLS 
Volker  Linnemann 
September  1980 

CSRG-1 18  S/SL;  SYNTAX/SEMANTIC  L/YNGUAGE 
INTRODUCTION  AND  SPECIFICATION 
R.C.  Holt,  J.R.  Cordy,  D.B.  Wortman 
CSRG,  September  19B0 

CSRG-1 19  PT;  A  PASCAL  SUBSET 
Alan  Rosselet 

[M.Sc.  Thesis,  DCS,  October  1930] 

CSRG-120  PTED:  A  STANDARD  PASCAL  TEXT  EDITOR  BASED  ON 
THE  KERNIGHAN  AND  PLAUGER  DESIGN 
Ken  Ne'vrman,  DCS 
October  1980 

CSRG-121  TERMINAL  CONTEXT  GRAMMARS 
Howard  W.  Trickey 
[M.Sc.  Ttiesis,  EE,  September  1960] 

CSRG-122  THE  APPROXIMATE  SOLUTION  OF  LARGE  QUEUEING 
NETWORK  MODELS 
John  Zahorjan 

[Ph.D.  Thesis,  DCS.  August  1980] 


11  - 


CSRG-123  A  FORMAL  TREATMENT  OF  IMPERFECT  INFOI^MATION 
IN  DATAllASK  MANAGEMENT 
Yarmis  Vassiliou 

[Ph.D.  Thesis,  DCS,  September  1980] 

C3RG- 124  AN  ANALYTIC  MODEL  OF  PHYSICAL  DATABASES 
Don  S.  Batory 

[Ph.D.  Thesis,  DCS,  January  1951] 

CSRG-125  MACHINE-INDEPENDENT  CODE  GENERATION 
Richard  PL  Kozlak 
[M.Sc.  Thesis,  DCS.  January  19811 


CSRG-126  COMPUTER  MACRO-SCHEDULING  FOR  HIGH  PRODUCTIVITY' 
.Abraham  Schoiibach 
[Ph.D.  Thesis,  DCS,  March  1981] 


CSRG-127  OMEGA  *UPHA 

D.  T.sichritzis  (cd.),  March  1931 


CSRG128  DI.ALOGUE  AND  PROCESS  DESIGN  T’OR  INTER^ACTIVE 
INFORMATION  SYSTEMS  USING  TAXIS 
John  Barron,  April  1981 
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